Best practice for sending large messages to ServiceBus
We need to post big messages on ServiceBus topics. The current size is about 10 MB. Our initial solution is to save a temporary file to BlobStorage and then send a message with a link to the blob. The file is compressed to save download times. It works great.
I read this article today: http://geekswithblogs.net/asmith/archive/2012/04/10/149275.aspx The suggestion is to split the post into smaller chunks and, on the host, fill them in again.
I can admit that this is a "cleaner approach" by avoiding going to BlobStore. On the other hand, I prefer to keep things simple. The cleavage mechanism introduces increased complexity. I mean, there must be a reason why they didn't include this in ServiceBus from the beginning ...
Has anyone tried the real life separation approach?
Are there any better templates?
source to share
I wrote this blog post a while ago, the intention was to implement a splitter and aggregator using Service Bus. I found this question by accident while looking for a better alternative.
I agree that the simplest approach might be to use a Blob store to store the body of the post and send a link to the post in the post. This is the scenario we are looking at for a client project right now.
I remember a couple of years ago, some example code was posted that will divert Service Bus and Store queues from the client application and optionally use Blob store for large message bodies. (I think it was the CAT team at Microsoft, but I'm not sure).
I can't find a sample with a quick google search, but as it can be a couple of years old it will be out of date as the Service Bus client library has been improved since then.
I used message splitting when the message size was too large, but since this was for batch telemetry data, there is no need to collect messages, and I could just handle multiple smaller batches on the receiving end of one large message.
Another disadvantage of the splitter-aggregator approach is that it requires sessions and therefore the session includes a queue or subscription. This means that all messages will require sessions, even smaller ones, and the session ID cannot be used for any other purpose in the implementation.
If I were you, I wouldn't trust the code on the blog, it was written a long time ago and I've learned a lot since then :-).
The Blob Storage approach is probably fine.
Hello,
Alan
source to share