this is expected behaviour because the redelivery is handled by the message consumer, so it is entirely client side. The broker just sees a consumer connect and close. The broker does keep a redelivery count in memory (by default) so the message consumer can respect that when it comes to client side redeliveries. The broker increments that count when a consumer closes for each message message has been consumed and not acked.
By default the message redelivery count is in memory only, see https://issues.apache.org/jira/browse/AMQ-3519 for details on making is persistent. On 26 November 2013 14:31, jstordeur <[email protected]> wrote: > Hi, > > I am using AMQ v5.8, I have a client listening to a queue and using > transacted session and persistent messages. > When I close my client before committing, the session is destroyed and the > message redelivered as expected, and after 6 redeliveries (the default > value) the message is moved to the DLQ. > > Now when I kill the client using kill -11, I do not observe the same > behavior. > Does that mean that if a message is harmful enough to crash the client > application (segfault for example), the message will be redelivered again > and again and never moved to the DLQ? > > Also I noticed that if I crash the client with a segfault 6 times, and then > the 7th I just close it normally, then the message is moved to the DLQ which > seems to indicate that somehow the broker knows that the message has already > been delivered several times. > > Thank you for your time. > J.Stordeur > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Handling-client-crash-induced-by-a-message-tp4674849.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. -- http://redhat.com http://blog.garytully.com
