jsr343-experts@jms-spec.java.net

[jsr343-experts] (JMS_SPEC-38) Allow JMS clients to specify whether a message is compressed in transit

From: Nigel Deakin <nigel.deakin_at_oracle.com>
Date: Fri, 05 Aug 2011 11:31:34 +0100

I have logged the following issue:
http://java.net/jira/browse/JMS_SPEC-38

This issue was raised by Emran. Here's my own description of the issue.

Emran: can you provide some more information of what you would like to see, and why you believe it is needed?

--------------

This is a request to allow JMS clients to define whether a message is compressed in transit, perhaps on a per-message
basis or more globally.

JMS providers are currently free to decide for themselves whether to compress a message, and many do, so the question
here is whether it is desirable to allow clients to control this via the API rather than via provider configuration
features.

--------------


My own feeling is that there isn't a need for this. Many providers already offer message compression. The JMS spec
deliberately doesn't define the wire format of a message and so providers are free to compress messages in transit if
they wish to.

In my view, message compression is best configured using global settings in the provider rather than on a per-message
basis. This is because whether message compression is needed for a given message depends on the performance
characteristics of the provider itself: there is a trade-off between the extra time needed to compress and decompress a
large message and the time saved in sending a smaller message down the wire. This trade-off will vary from provider to
provider, and so allowing the application code to directly configure whether a message is compressed would reduce its
portability.

A further reason for keeping message compression as a provider-specific configuration option rather than as part of the
JMS API is that it allows providers to decide for themselves what configuration options they want to provider. Some
providers may not support message compression at all. Others may offer a global switch to sllow message compression to
be switched on or off. Others may allow message compression to be defined on a per-destination basis. Other may allow
the administrator to define a size threshold above which messages will be compressed. Finally, some providers may allow
the administrator to configure what compression algorithm is used. I feel this is an area where it is beneficial to
allow providers to differ and offer whatever features that they believe provide best performance.

Would anyone else like to comment? Obviously, since Emran raised this issue we need to hear his views before coming to
any decision.

Nigel