HornetQ (in AS trunk) ends up in infinite redeliveries
jaikiran Apr 16, 2010 9:05 AMSlightly related to this discussion http://community.jboss.org/message/537904#537904
We have got a MDB, in EJB3 testsuite, which does this (intentionally):
public void onMessage(Message message) { System.out.println("*** DlqTestMDB onMessage, delivery count=" + (++count) + " is redelivered? " + message.getJMSRedelivered()); throw new RuntimeException("force resend"); }
The HornetQ docs says that the default max delivery count is 10. However in AS trunk, I see that this message gets redelivered infinitely. Also, the message.getJMSRedelivered returns false always. Looking at HornetQ code (QueueImpl#checkDLQ), I can see that the maxDeliveryCount is picked up as 10 (the default), but the MessageReference#getDeliveryCount always returns 0 and as a result the message is re-delivered infinitely and never gets sent to DLQ.
This looks somehow related to the persist-delivery-count-before-delivery config mentioned in the hornetq doc:
21.3. Delivery Count Persistence
In normal use, HornetQ does not update delivery count persistently until a message is rolled back (i.e. the delivery count is not updated before the message is delivered to the consumer). In most messaging use cases, the messages are consumed, acknowledged and forgotten as soon as they are consumed. In these cases, updating the delivery count persistently before delivering the message would add an extra persistent step for each message delivered, implying a significant performance penalty.
However, if the delivery count is not updated persistently before the message delivery happens, in the event of a server crash, messages might have been delivered but that will not have been reflected in the delivery count. During the recovery phase, the server will not have knowledge of that and will deliver the message with redelivered set to false while it should be true.
As this behavior breaks strict JMS semantics, HornetQ allows to persist delivery count before message delivery but disabled it by default for performance implications.
To enable it, set persist-delivery-count-before-delivery to true in hornetq-configuration.xml:
<persist-delivery-count-before-delivery>true</persist-delivery-count-before-delivery>
Looking at the AS hornetq-configuration.xml, I don't see this being set. I think this should be set in the AS by default, or else it breaks the JMS semantics. I locally, added that property, but haven't seen any difference to the behaviour.
Am I missing something?