[JMS_SPEC-21] Support for pre-acknowledge ack mode Created: 08/Jun/11  Updated: 14/Oct/15

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: timlfox Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
is related to JMS_SPEC-168 No-acknowledge mode Open
Tags: pd20-forreview-major


Many messaging systems allow messages to be automatically acknowledged on the server before they are delivered to their consumers. This feature is useful for transient messaging use cases where it does not matter if some messages are lost on failure (e.g. stock pricing information).

JMS does not currently provide an acknowledgment mode which supports pre-acknowledgment on the server, so there's extra (unnecessary) traffic due to acks having to be sent from client--server.

In reality most JMS implementations provide pre-ack as an extension to the set of JMS ack modes. I would like to propose that pre-ack is added to the list of standard ack modes in JMS.

Comment by Nigel Deakin [ 08/Jun/11 ]

Can you give more information about what you mean by "pre-acknowledgment on the server"?

Comment by timlfox [ 08/Jun/11 ]

In JMS messages are not removed from the server, and are available for redelivery until they are acknowledge by the client. This occurs by the client either:

a) Committing a transaction
b) Explicitly acking CLIENT_ACKNOWLEDGE
c) Acks being sent from the client when either DUPS_OK_ACKNOWLEDGE or AUTO_ACKNOWLEDGE is used

In all above cases it requires traffic from the client to the server for the acks

In many cases (e.g. transient messaging, stock prices), the messages are dispensable, it doesn't matter if a few are lost on event of failure. In such a case it makes sense for the server to automatically ack the message before delivery to the consumer.

This can result in less traffic and less work to do on the client, also the server can get rid of the message immediately after delivery and does not have to retain it for possible future redelivery.

This is already implemented by messaging systems including HornetQ and Weblogic JMS. Would be nice to have this in the JMS spec since it's such a common extension.

Comment by timlfox [ 08/Jun/11 ]

In weblogic this is called NO_ACKNOWLEDGE http://download.oracle.com/docs/cd/E13222_01/wls/docs81/javadocs/weblogic/jms/extensions/WLSession.html#NO_ACKNOWLEDGE

In HornetQ it's called pre-acknowledge

Comment by Nigel Deakin [ 22/Feb/12 ]

The fact that two vendors support this already makes this a good candidate for inclusion in JMS. I will formally raise this with the Expert Group for possible inclusion in the Public Draft. Setting appropriate tag.

Generated at Tue Mar 28 11:41:58 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.