On 09/08/2011 05:56, emran wrote:
> 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.
I've just updated the JIRA issue for this
http://java.net/jira/browse/JMS_SPEC-38
to record the discussion and decision to drop this issue.
I've closed the issue with a status of "Won't Fix".
The list of useful queries at
http://java.net/projects/jms-spec/pages/Home#Useful_JIRA_queries
now includes a query of such "rejected" issues. This is the first!
Nigel
>
> ----- 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
>>
>