From c1983510617bf1eecd1e03453e5b7f6f082cfd0b Mon Sep 17 00:00:00 2001 From: Artem Bilan Date: Wed, 14 Dec 2011 18:50:25 +0200 Subject: [PATCH] INT-2236: limitations while using persistent MessageStore --- docs/src/reference/docbook/message-store.xml | 32 ++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/docs/src/reference/docbook/message-store.xml b/docs/src/reference/docbook/message-store.xml index 9ca1f0c194..f319797e43 100644 --- a/docs/src/reference/docbook/message-store.xml +++ b/docs/src/reference/docbook/message-store.xml @@ -56,4 +56,36 @@ + + + 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 by default only Serializable data is persisted. + 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 after (e.g., FTP, HTTP, JMS etc.). + For example: <http:inboubd-channel-adapter/> applies all HTTP-headers into Message Headers and one of them is + ArrayList of non-Serializable org.springframework.http.MediaType. + However you are able to inject your own serialization strategy as implementation of special interfaces into MessageStore to + change behaviour of serialization and deserialization. + + + Special attention must be payed 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'll end up with the different instance of the last one, + 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 deserilized channel would not represent the expected instance. + As a workaround we suggest to remove bean-refs headers via <header-filer/> + before sending message to some endpoint backed by persistence MessageStore + and use 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 message-flow like this: gateway -> queue-channel (backed by persistence Message Store) -> service-activator. + Created on the background Temporary Reply Channel will be lost after reading from queue by service-activator poller, because it will deserialized in another thread. + + + Nevertheless we constantly thinking about potential improvements to the framework to provide some robust default serialization strategy for messages. + + + +