INT-3978 Fix MessageHistory for Message types
#1764
Conversation
JIRA: https://jira.spring.io/browse/INT-3978 Previously the `MessageHistory.write()` always used `MessageBuilder` to populated the `history` header. Since the `MessageBuilder` doesn't care about the `source` message type, we might lose some important information, like `AdviceMessage.inputMessage` * Add conditional logic into the `MessageHistory` for all known `Message<?>` implementations * Provide appropriate tests in the `MessageHistoryTests` for known `Message<?>` implementations * Make `AdviceMessage` generic and fix all affected code on the matter * Since `MutableMessage` is public already, fix `MongoDbMessageStore.DBObjectToMutableMessageConverter` to use `MutableMessage` type directly.
| } | ||
| else { | ||
| message = messageBuilderFactory.fromMessage(message).setHeader(HEADER_NAME, history).build(); | ||
| } |
There was a problem hiding this comment.
I wonder if we should consider making the message history header mutable - via a MessageHistoryHolder; that way, we only have to rebuild the message in the first trackable component; each subsequent track would still get a new MessageHistory and each MB.build() would have to detect an existing holder, create a new one and transfer the existing history.
That way, pub/subs etc would inherit the history to-date, but have a unique holder so changes on one leg of the pub/sub would not be reflected in the other other leg. If the MB.build() didn't create a new holder, we'd get cross-talk.
Since MessageHistory is already a container object, we should be able to avoid a new class - just clone it in MB and replace the components on new writes.
|
Pushed. |
|
I don't think we can rely on a boolean like that - we don't know what user code might do - they might Instead, just have the message builder detect if there is a history object and replace it with a new one (with the same contents) and, in message history write, if there's already contents, clone them and add the new track. This won't work because the contents are shared - we need new contents every time. Since this is a bit complicated, it should perhaps be a different JIRA and not done as part of this fix but I definitely want to look at it for performance reasons. |
|
Reverted the performance tuning PoC. |
| ((AdviceMessage) message).getInputMessage()); | ||
| } | ||
| else { | ||
| message = messageBuilderFactory.fromMessage(message).setHeader(HEADER_NAME, history).build(); |
There was a problem hiding this comment.
Perhaps add a DEBUG log (or WARN?) for not-recognized message types (e.g. User) ?
|
Pushed the |
|
Merged as 1df7815 |
JIRA: https://jira.spring.io/browse/INT-3978
Previously the
MessageHistory.write()always usedMessageBuilderto populated thehistoryheader.Since the
MessageBuilderdoesn't care about thesourcemessage type, we might lose some important information,like
AdviceMessage.inputMessageMessageHistoryfor all knownMessage<?>implementationsMessageHistoryTestsfor knownMessage<?>implementationsAdviceMessagegeneric and fix all affected code on the matterMutableMessageis public already, fixMongoDbMessageStore.DBObjectToMutableMessageConverterto useMutableMessagetype directly.