Hello, I have read about the true messaging and that instead of sending payload on the bus, it sends an identifier. In our case, we have a lot of legacy apps/services and those were designed to receive the payload of messages (xml) that is close to 4MB (close MSMQ limit). Is there a way for nService bus to handle large payload and persist messages automatically or another work-around, so that the publisher/subscriber services don't have to worry neither about the payload size, nor about how to de/re-hydrate the payload? Thank you in advance.
A:
I'm not aware of any internal NServiceBus capability to associate extra data with a message out of band.
I think you're right on the mark - if the entire payload can't fit within the limit, then it's better to persist it elsewhere on your own and then passing an ID.
However, it may be possible for you to design a message structure such that a message could implement an IHasPayload interface (which would perhaps incorporate an ID and a Type?), and then your application logic could have a common method for getting the payload given an IHasPayload message.
David
2010-05-04 15:07:13
Thank you David,Thought about something similar to this, but then you need another subsystem that would serve as a repository (like DB) and your messages dependent of that subsystem to be up and running. This adds complexity both to the overall solution and message reliability and all related to that. I was hoping to find something different I guess (not a miracle, but a nBusService feature I might not be aware).
Sean
2010-05-05 12:04:08
+1
A:
You could use the Message Sequence pattern. In NServiceBus, you would split the payload in the sender, wrap the chunks in a custom 'Sequence' IMessage, and then implement a saga at the other end to extract the chunks & reassemble. You would need to put some effort into error handling & timeouts.
Sam
2010-05-20 01:02:27
Thank you Sam. That is an option. The more I read, the more I see that with messaging I should really leave payload out, and query for it when it's needed.
Sean
2010-05-20 13:40:19
Hi Sean - it's a trade-off depending on what your requirements are. If you can't live with the prospect your claim check payload store might be down, you'll want to use a message sequence instead.
Sam
2010-05-21 01:24:43
A:
You can always use the quick "fix" of compressing the messages.
A POCO serialized with the binary serializer can be compressed down by a large margin. We saw our messages that were 20mb compressed down to 3.1mb.
So if your messages are hovering around 4mb it might be simple to just write an IMessageSerializer that automatically compresses the message while it is on the wire.
Gord
2010-06-17 15:30:40