In addition to the earlier comment by @AlexR, BytesMessage has a getBodyLength () method
http://download.oracle.com/javaee/1.4/api/javax/jms/BytesMessage.html#getBodyLength
and you can probably estimate the typical size of the header in the path by capturing several objects created using Session.createMessage () - that is, a JMS message type without a payload. I think I will be tempted to work directly with the payload in byte [] using BytesMessage and compress via ZipOutputStream if the bandwidth is critical. In addition, JMS allows hints to suppress message timestamps and message identifiers, which can help reduce message size, for example.
http://download.oracle.com/javaee/1.4/api/javax/jms/MessageProducer.html#setDisableMessageTimestamp%28boolean%29
although providers are not required to support it,
If the JMS provider accepts this prompt, these messages must have a message identifier of null; if the provider ignores the prompt, the message identifier must be set to its usual unique value
I once worked with bandwidth-limited JMS in WebSphere MQ, and it was possible that the message size was quite small, although the wireframe format was also optimized for size in this case
strmqm
source share