activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Bertram <>
Subject Re: Artemis 1.5.1 STOMP problem with NACK
Date Mon, 09 Jan 2017 13:34:13 GMT
The behavior you're seeing is the intended behavior.  If you NACK a message it is dropped,
which is a valid behavior based on the 1.2 specification.

If you would prefer a different behavior you could try a few different things:

  1) Send a PR to the Artemis GitHub repository to implement the behavior you want.
  2) Lower the connection TTL so failed client connections are cleaned up more quickly.
  3) Try using a transaction for consuming and rolling back that transaction instead of sending


----- Original Message -----
From: "Maciej GaƂkowski" <>
Sent: Saturday, January 7, 2017 12:29:53 PM
Subject: Artemis 1.5.1 STOMP problem with NACK

I am evaluating STOPM v1.2 protocol implementation. In our use case STOMP
message consumers have to call an unreliable third party dependency, and
this call can fail from time to time.
The subscription is set in the ack:client-individual mode.

When my consumer is set to not send any ACKs in case of external call
failure, then the messages are redelivered to another consumer only when
the broker connection to the first consumer dies. This is manageable, but
not very practical either.

I did assume that if the consumer sends NACKs if the external call fails,
then the message will be redelivered to another consumer after the
<redelivery-delay> time.
Unfortunately, if I send a NACK from the consumer, then it looks like the
request is simply dropped. Is it intended? Can I configure Artemis to try
to redeliver messages that have been NACK'ed ?

My <address-settings> looks like this:
         <!--default for catch all-->
         <address-setting match="#">
            <!-- with -1 only the global-max-size is in use for limiting -->


I can paste the whole broker.xml if necessary

View raw message