download PDF
JMS specifies three acknowledgement modes:
HornetQ supports two additional modes: PRE_ACKNOWLEDGE and INDIVIDUAL_ACKNOWLEDGE.
In some scenarios you could afford to lose messages in event of failure, so it would help to acknowledge the message on the server before delivering it to the client.
This extra mode is supported by HornetQ and is called as pre-acknowledge mode.
The disadvantage of acknowledging the messages on the server before delivery is that the message is lost if the system crashes after acknowledging the message on the server but before it is delivered to the client. In that case, the message is lost and will not be recovered when the system restart.
Depending on the messaging case, pre-acknowledgement mode can avoid extra network traffic and CPU at the cost of coping with message loss.
An example use case for pre-acknowledgement is related to stock price update messages. With these messages it might be reasonable to lose a message in event of crash, since the next price update message will arrive soon, overriding the previous price.


If you use pre-acknowledge mode, then you will lose transactional semantics for messages being consumed, since they are being acknowledged first on the server, not when you commit the transaction.


The pre-acknowledgement mode can be configured in the standalone.xml or domain.xml file on the connection factory.
<connection-factory name="ConnectionFactory">
      <connector-ref connector-name="netty-connector"/>
      <entry name="ConnectionFactory"/>
Alternatively, to use pre-acknowledgement mode using the JMS API, create a JMS Session with the HornetQSession.PRE_ACKNOWLEDGE constant.
// messages will be acknowledge on the server *before* being delivered to the client
Session session = connection.createSession(false, HornetQJMSConstants.PRE_ACKNOWLEDGE);
Alternatively, you can set pre-acknowledge directly on the HornetQConnectionFactory instance using the setter method.
To use pre-acknowledgement mode using the core API you can set it directly on the ClientSessionFactory instance by using the setter method.

18.9.2. Individual Acknowledge

A valid use-case for individual acknowledgement is when you need to have your own scheduling and you do not know when your message processing will be finished. You prefer having one consumer per thread worker but this is not possible in some circumstances depending on how complex is your processing. For that you can use the individual acknowledgement.
You must setup Individual Acknowledge by creating a session with the acknowledge mode with HornetQJMSConstants.INDIVIDUAL_ACKNOWLEDGE. Individual Acknowledge inherits all the semantics from Client Acknowledge, with the exception the message is individually acknowledged.


To avoid confusion on MDB processing, Individual ACKNOWLEDGE is not supported through MDBs (or the inbound resource adapter). This is because you have to finish the process of your message inside the MDB
Red Hat logoGithubRedditYoutubeTwitter


Try, buy, & sell


About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.