Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      n/a

      Description

      Currently the JMS 1.1 and 2.0 specifications only allow for one mode of operation for applications which wish to do their own message acknowledgment. This is CLIENT_ACKNOWLEDGE mode. This mode has the following characteristic, as defined in the spec: "Acknowledging a consumed message automatically acknowledges the receipt of all messages that have been delivered by its session.".

      This Implicit acknowledgment of all messages is not only somewhat unexpected, because it's such a broad side effect, it is highly inconvenient in cases where message processing is being done by multiple threads asynchronously (message reception on one Session has to be in a single thread, per JMS spec rules, but I am talking about cases where the messages are then dispatched to one or more worker threads, or even other processes, for asynchronous processing). I realise this can be overcome to some degree by using a separate Session and MessageConsumer in each worker thread, but that imposes more overhead on the JMS provider. A better alternative, which is already offered by certain JMS providers (including Tibco EMS and ActiveMQ), is INDIVIDUAL_ACKNOWLEDGE mode, where acknowledging a message acknowledges only that message. This makes asynchronous processing of messages much easier to implement.

      One can imagine other acknowledge modes that would be useful too, for example: CONSUMER_ACKNOWLEDGE where Message.acknowledge() would acknowledge only messages received up on a particular MessageConsumer, or CONSUMER_CHECKPOINT_ACKNOWLEDGE where Message.acknowledge() would acknowledge only messages received up to and including the Message instance on which the method was called.

      But without embarking on all these various different possibilities, would it be possible to consider just adding INDIVIDUAL_ACKNOWLEDGE mode? This alone would make it possible for multithreaded applications to achieve whatever behaviors they need.

        Issue Links

          Activity

          Hide
          Nigel Deakin added a comment -

          @Chris: Yes, I've just added it to that page (and added an appropriate tag). Thanks for spotting that this issue was in danger of being forgotten. This put the issue on the agenda for formal discussion for 2.1 - nothing has been decided yet.

          Show
          Nigel Deakin added a comment - @Chris: Yes, I've just added it to that page (and added an appropriate tag). Thanks for spotting that this issue was in danger of being forgotten. This put the issue on the agenda for formal discussion for 2.1 - nothing has been decided yet.
          Hide
          chris.barrow added a comment -

          Another JMS provider which supports individual acknowledgement is Tibco EMS:
          https://docs.tibco.com/pub/enterprise_message_service/6.3.0-february-2012/doc/html/tib_ems_api_reference/api/javadoc/com/tibco/tibjms/Tibjms.html#EXPLICIT_CLIENT_ACKNOWLEDGE
          (non-standard acknowledgement mode EXPLICIT_CLIENT_ACKNOWLEDGE which alters the behavior of message#acknowledge())

          Show
          chris.barrow added a comment - Another JMS provider which supports individual acknowledgement is Tibco EMS: https://docs.tibco.com/pub/enterprise_message_service/6.3.0-february-2012/doc/html/tib_ems_api_reference/api/javadoc/com/tibco/tibjms/Tibjms.html#EXPLICIT_CLIENT_ACKNOWLEDGE (non-standard acknowledgement mode EXPLICIT_CLIENT_ACKNOWLEDGE which alters the behavior of message#acknowledge())
          Hide
          chris.barrow added a comment -

          I like Clebert's suggestion of CLIENT_INDIVIDUAL_ACKNOWLEDGE. It goes nicely with CLIENT_ACKNOWEDGE,

          Show
          chris.barrow added a comment - I like Clebert's suggestion of CLIENT_INDIVIDUAL_ACKNOWLEDGE. It goes nicely with CLIENT_ACKNOWEDGE,
          Hide
          Nigel Deakin added a comment -

          The specification for Session#getAcknowledgementMode and JMSContext#getSessionMode would need to be extended to cover this new feature.

          Show
          Nigel Deakin added a comment - The specification for Session#getAcknowledgementMode and JMSContext#getSessionMode would need to be extended to cover this new feature.
          Hide
          gemmellr added a comment -

          Individual acknowledgement of messages would seem to be a useful thing to support. There is work ongoing on a AMQP mapping for JMS over at OASIS, and individual acknowledge is an area of functionality that there isn't currently a natural fit for in JMS. Supporting this would also allow enabling the behaviour I have seen several people actually think the existing method had until they use it and discover otherwise; the javadoc is perfectly clear on the behaviour of course, but requires that they read it first.

          Between the mentioned routes for implementation thus far, I would personally prefer the route of adding a new ack mode such as CLIENT_INDIVIDUAL_ACKNOWLEDGE and using it to govern the behaviour of Message#acknowledge(). This seems the most intuitive to me given it is a different mode of acknowledgement, the acknowledge action is on the message, and doing so would enable the kind of behaviour that people often think is already offered by the method. From above, it also seems to be how more of the existing vendor extensions approach offering the functionality.

          Show
          gemmellr added a comment - Individual acknowledgement of messages would seem to be a useful thing to support. There is work ongoing on a AMQP mapping for JMS over at OASIS, and individual acknowledge is an area of functionality that there isn't currently a natural fit for in JMS. Supporting this would also allow enabling the behaviour I have seen several people actually think the existing method had until they use it and discover otherwise; the javadoc is perfectly clear on the behaviour of course, but requires that they read it first. Between the mentioned routes for implementation thus far, I would personally prefer the route of adding a new ack mode such as CLIENT_INDIVIDUAL_ACKNOWLEDGE and using it to govern the behaviour of Message#acknowledge(). This seems the most intuitive to me given it is a different mode of acknowledgement, the acknowledge action is on the message, and doing so would enable the kind of behaviour that people often think is already offered by the method. From above, it also seems to be how more of the existing vendor extensions approach offering the functionality.

            People

            • Assignee:
              Unassigned
              Reporter:
              chris.barrow
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated: