jms-spec
  1. jms-spec
  2. JMS_SPEC-38

Allow JMS clients to specify whether a message is compressed in transit

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Labels:
      None

      Description

      This issue was raised by a member of the JSR 343 Expert Group and is logged here to allow the issue to be discussed and tracked.

      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.

        Activity

        Hide
        colincrist added a comment - - edited

        I'd say this is an administrative configuration in the provider and out of the scope of the API. Allowing each endpoint to choose makes administering a large install a headache as you need a code change to enable compression.

        Better for the provider to be configured centrally to make a client compress based on username/clientID/queue/topic/wildcard

        Show
        colincrist added a comment - - edited I'd say this is an administrative configuration in the provider and out of the scope of the API. Allowing each endpoint to choose makes administering a large install a headache as you need a code change to enable compression. Better for the provider to be configured centrally to make a client compress based on username/clientID/queue/topic/wildcard
        Hide
        Nigel Deakin added a comment -

        I don't think there's 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 allow 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.

        Show
        Nigel Deakin added a comment - I don't think there's 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 allow 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.
        Hide
        Nigel Deakin added a comment -

        We've discussed this on the JSR 343 expert group and the original proposer and decided not to proceed with this proposal. I'm therefore closing this issue with a resolution of "won't fix"

        Show
        Nigel Deakin added a comment - We've discussed this on the JSR 343 expert group and the original proposer and decided not to proceed with this proposal. I'm therefore closing this issue with a resolution of "won't fix"

          People

          • Assignee:
            Nigel Deakin
            Reporter:
            Nigel Deakin
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: