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

          chris.barrow created issue -
          Nigel Deakin made changes -
          Field Original Value New Value
          Tags pd20-forreview-major
          Hide
          chris.barrow added a comment - - edited

          Note that the above use case would require relaxing the threading rules for a Session to allow <Message>.acknowledge() to be called in threads other than the JMS provider thread which is delivering messages, at least in the case where INDIVIDUAL_ACKNOWLEDGE mode is set on the session. So it would be desirable to include that relaxation along with this feature.

          The relevant parts of the JMS 1.1 spec are 4.4 "Session" which states (in a footnote) that "the restriction is that the resources of a Session should not be used concurrently by multiple threads" and section 4.4.6 "Conventions for Using a Session" which explains "Once a connection has been started, all its sessions with a registered message listener are dedicated to the thread of control that delivers messages to them.".

          Currently the only exception to this rule is that the Session.close method may be called outside the thread of control. The feature described by this ticket would require an additional exception: that the Message.acknowledge() method can be called outside the thread of control (at least when the session acknowledge mode is INDIVIDUAL_ACKNOWLEDGE).

          Show
          chris.barrow added a comment - - edited Note that the above use case would require relaxing the threading rules for a Session to allow <Message>.acknowledge() to be called in threads other than the JMS provider thread which is delivering messages, at least in the case where INDIVIDUAL_ACKNOWLEDGE mode is set on the session. So it would be desirable to include that relaxation along with this feature. The relevant parts of the JMS 1.1 spec are 4.4 "Session" which states (in a footnote) that "the restriction is that the resources of a Session should not be used concurrently by multiple threads" and section 4.4.6 "Conventions for Using a Session" which explains "Once a connection has been started, all its sessions with a registered message listener are dedicated to the thread of control that delivers messages to them.". Currently the only exception to this rule is that the Session.close method may be called outside the thread of control. The feature described by this ticket would require an additional exception: that the Message.acknowledge() method can be called outside the thread of control (at least when the session acknowledge mode is INDIVIDUAL_ACKNOWLEDGE).
          Hide
          chris.barrow added a comment -

          It is perhaps worth pointing out that allowing the <Message>.acknowledge() method to acknowledge only that message would fit in nicely with the proposal to support the acknowledge () method on Session (see issue JMS_SPEC-68).

          Show
          chris.barrow added a comment - It is perhaps worth pointing out that allowing the <Message>.acknowledge() method to acknowledge only that message would fit in nicely with the proposal to support the acknowledge () method on Session (see issue JMS_SPEC-68 ).
          Hide
          tom.barnes added a comment -

          A potential alternate API to the proposed new acknowledge modes INDIVIDUAL_ACKNOWLEDGE and CONSUMER_CHECKPOINT_ACKNOWLEDGE could be new Session methods “acknowledgeOne(Message)” and “acknowledgeUpThrough(Message)”. These new methods, like the current "message.acknowledge()" and the proposed "session.acknowledge()", would only apply in CLIENT_ACKNOWLEDGE mode.

          This would eliminate the need to add new acknowledge modes, and would preserve the semantics of the old "acknowledge()" verb so that it always had the same legacy behavior.

          Show
          tom.barnes added a comment - A potential alternate API to the proposed new acknowledge modes INDIVIDUAL_ACKNOWLEDGE and CONSUMER_CHECKPOINT_ACKNOWLEDGE could be new Session methods “acknowledgeOne(Message)” and “acknowledgeUpThrough(Message)”. These new methods, like the current "message.acknowledge()" and the proposed "session.acknowledge()", would only apply in CLIENT_ACKNOWLEDGE mode. This would eliminate the need to add new acknowledge modes, and would preserve the semantics of the old "acknowledge()" verb so that it always had the same legacy behavior.
          Hide
          clebertsuconic added a comment -

          This issue should be broken in two...one about INDIVIDUAL_ACKNOWLEDGE which is already implemented in a few implementation (I know for instance both hornetQ and ActiveMQ have it).

          I'm ok with INDIVIDUAL_ACKNOWLEDGE... but I feel session.acknowledge() is a bit not doable.

          by adding INDIVIDUAL_ACKNOWLEDGE mode you can change the semantic of message.acknowledge() as most providers already do. It's a minor change in semantic anyways as you only ack that message which is exactly what the user would expect in such case.

          Of course this would only apply to non-transactional, same way as the CLIENT_ACKNOWLEDGE is done. INDIVIDUAL_ACKNOWLEDGE would just be a different CLIENT_ACK mode.

          you could even maybe call it CLIENT_INDIVIDUAL_ACKNOWLEDGE but I guess a short name woud be better... INDIVIDUAL_ACKNOWLEDGE.

          Show
          clebertsuconic added a comment - This issue should be broken in two...one about INDIVIDUAL_ACKNOWLEDGE which is already implemented in a few implementation (I know for instance both hornetQ and ActiveMQ have it). I'm ok with INDIVIDUAL_ACKNOWLEDGE... but I feel session.acknowledge() is a bit not doable. by adding INDIVIDUAL_ACKNOWLEDGE mode you can change the semantic of message.acknowledge() as most providers already do. It's a minor change in semantic anyways as you only ack that message which is exactly what the user would expect in such case. Of course this would only apply to non-transactional, same way as the CLIENT_ACKNOWLEDGE is done. INDIVIDUAL_ACKNOWLEDGE would just be a different CLIENT_ACK mode. you could even maybe call it CLIENT_INDIVIDUAL_ACKNOWLEDGE but I guess a short name woud be better... INDIVIDUAL_ACKNOWLEDGE.
          Hide
          Nigel Deakin added a comment -

          JMS providers which support individual acknowledgement as a non-standard extension:

          GlassFish Message Queue
          http://docs.oracle.com/cd/E18930_01/html/821-2440/aeqef.html#scrolltoc
          (methods on the provider's message implementation: acknowledgeThisMessage() and acknowledgeUpThroughThisMessage())

          ActiveMQ
          http://activemq.apache.org/maven/apidocs/org/apache/activemq/ActiveMQSession.html#INDIVIDUAL_ACKNOWLEDGE
          (new non-standard acknowledgement mode {[INDIVIDUAL_ACKNOWLEDGE}} which alters the behaviour of Message#acknowledge()

          JBoss HornetQ
          http://docs.jboss.org/hornetq/2.3.0.beta1/docs/user-manual/html/pre-acknowledge.html#individual-ack
          (new non-standard acknowledgement mode INDIVIDUAL_ACKNOWLEDGE)

          Show
          Nigel Deakin added a comment - JMS providers which support individual acknowledgement as a non-standard extension: GlassFish Message Queue http://docs.oracle.com/cd/E18930_01/html/821-2440/aeqef.html#scrolltoc (methods on the provider's message implementation: acknowledgeThisMessage() and acknowledgeUpThroughThisMessage() ) ActiveMQ http://activemq.apache.org/maven/apidocs/org/apache/activemq/ActiveMQSession.html#INDIVIDUAL_ACKNOWLEDGE (new non-standard acknowledgement mode {[INDIVIDUAL_ACKNOWLEDGE}} which alters the behaviour of Message#acknowledge() JBoss HornetQ http://docs.jboss.org/hornetq/2.3.0.beta1/docs/user-manual/html/pre-acknowledge.html#individual-ack (new non-standard acknowledgement mode INDIVIDUAL_ACKNOWLEDGE )
          Hide
          John D. Ament added a comment -

          If we add INDIVIDUAL_ACKNOWLEDGE do we also need to add INDIVIDUAL_ACKNOWLEDGE_TX or equivalent, to individually change to TX mode.

          Show
          John D. Ament added a comment - If we add INDIVIDUAL_ACKNOWLEDGE do we also need to add INDIVIDUAL_ACKNOWLEDGE_TX or equivalent, to individually change to TX mode.
          Hide
          clebertsuconic added a comment -

          @John D. Ament: quick answero: no... there's no directly ack on messages on any TX mode. so no reason for that

          Show
          clebertsuconic added a comment - @John D. Ament: quick answero: no... there's no directly ack on messages on any TX mode. so no reason for that
          Hide
          chris.barrow added a comment -

          Can we get this onto the plan for JMS 2.1? Anything I can do to help?

          Show
          chris.barrow added a comment - Can we get this onto the plan for JMS 2.1 ? Anything I can do to help?
          Nigel Deakin made changes -
          Tags pd20-forreview-major jms21-forreview-minor pd20-forreview-major
          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,
          Nigel Deakin made changes -
          Link This issue is related to JMS_SPEC-168 [ JMS_SPEC-168 ]
          Nigel Deakin made changes -
          Link This issue is related to JMS_SPEC-169 [ JMS_SPEC-169 ]
          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.

            People

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

              Dates

              • Created:
                Updated: