diff --git a/docs/src/reference/docbook/message-store.xml b/docs/src/reference/docbook/message-store.xml index 9ca1f0c194..342a759038 100644 --- a/docs/src/reference/docbook/message-store.xml +++ b/docs/src/reference/docbook/message-store.xml @@ -56,4 +56,42 @@ + + + However be aware of some limitations while using persistent implementations of the MessageStore. + The Message data (payload and headers) is serialized and deserialized + using different serialization strategies depending on the implementation of the MessageStore. + For example, when using JdbcMessageStore, only Serializable data is persisted by default. + In this case non-Serializable headers are removed before serialization occurs. + Also be aware of the protocol specific headers that are injected by transport adapters (e.g., FTP, HTTP, JMS etc.). + For example, <http:inbound-channel-adapter/> maps HTTP-headers into Message Headers and one of them is an + ArrayList of non-Serializable org.springframework.http.MediaType instances. + However you are able to inject your own implementation of the Serializer and/or + Deserializer strategy interfaces into some MessageStore implementations + (such as JdbcMessageStore) to change the behaviour of serialization and deserialization. + + + Special attention must be paid to the headers that represent certain types of data. + For example, if one of the headers contains an instance of some Spring Bean, upon deserialization you may end + up with a different instance of that bean, + which directly affects some of the implicit headers created by the framework (e.g., REPLY_CHANNEL or ERROR_CHANNEL). + Currently they are not serializable, but even if they were the deserialized channel would not represent the expected instance. + As a workaround we suggest to remove bean-ref headers via a <header-filter/> + before sending a message to an endpoint backed by a persistent MessageStore. + Also, we recommend using channel names instead of channel instances when setting those types of headers, + thus allowing it to be resolved in real time by the ChannelResolver. + + + Also avoid configuration of a message-flow like this: + gateway -> queue-channel (backed by a persistent Message Store) -> service-activator + That gateway creates a Temporary Reply Channel in the background, and it will be lost by the time the + service-activator's poller reads from the queue, because it has been deserialized by another thread on the sending side. + + + Nevertheless we are constantly thinking about potential improvements to the framework, such as a way to provide some + robust default serialization strategy for messages in these cases. + + + +