Nigel,
I had the following in my mind :
Since the compress/de-compress is implemented by most of the providers, it
would be good to provide it on the ConnectionFactory API. While creating a
connection, we would pass an extra parameter which enables/disables
compression for the messages sent from that connection.
But, I think I would take back my proposal with the portability and
configuration/performance issues you mentioned.
Regards,
Emran.
----- Original Message -----
From: "Nigel Deakin" <nigel.deakin_at_oracle.com>
To: <jsr343-experts_at_jms-spec.java.net>
Sent: Friday, August 05, 2011 4:01 PM
Subject: [jsr343-experts] (JMS_SPEC-38) Allow JMS clients to specify whether
a message is compressed in transit
>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
>