Verify Message.Size functionality

[jtaubensee]

Actual Behavior

1. I have reason to believe that Message.Size will only calculate the size of a stream, and not the headers.

Expected Behavior

1. Message.Size should include the size of the headers

Versions

All

[SeanFeldman]

👍
This is an old pain. The current (we should really find a name to call it) client does a poor job, especially when querying the messages that were not sent yet.

[jtaubensee]

So, after looking into this one a little bit more, we are wondering where would be the best place to put this functionality. I think rather than being a property on the message, this should be a "utility function" somewhere (perhaps on the MessageSender). The reason being is that the size cannot be cached (as the body and properties are mutable), and in order to provide the true message size, we need to convert the message to an AMQP message first. Of course, there is some overhead associated with this, hence the reason to have a method called CalculateMessageSize.

Any thoughts about where this should go? Also, keep in mind that we will throw an exception on the client side before the message is sent if the size is too big. So in most cases, users can just handle the exception on send.

[SeanFeldman]

The message size is important to be assessed prior to sending it. Batching allows up to 100 messages or less than the maximum size for the tier used. If there are less than 100 messages, one has to calculate the overall size of the messages in order to make a conscious decision to split the batch into "chunks".

Utility method sounds off to be frank. The message is the one that should know how to calculate its size, not some method on an arbitrary class that might (or might not) be used later. Yes, calculation of the message time is a perf hit, but it's a necessary evil. And when someone opts into it, they probably do that for a good reason.

To sum it up:

• No to a utility method on something like MessageSender
• No to an assumption at what point that calculated size will be needed
• Yes for the Message to provide this method and proper documentation of what it's doing

If you really oppose the idea of Message providing the calculation, you could implement it as an extension method on the root namespace (along with the Message).