8 Replies Latest reply on Aug 4, 2010 2:55 AM by andreas_back

    JMSRedelivered after client crash

    andreas_back Novice

      Hello HornetQ-Team!


      It is very inspiring to test HornetQ and thank you for producing such a fast messaging server.


      While migrating from JBoss MQ we have seen some point according to message redelivery and client crash in JBoss Messaging, see https://community.jboss.org/thread/151962.


      This has led to a small test program where we investigated the reaction of HornetQ in this case. The following observation has been made.


      If the client crashes (for example shutdown of the JVM within the IDE) after the message has been received by (MessageConsumer c).receive(1000) but before it is acknowledged by the client then the following happens.


      1.     The message is not visible to the QueueBrowser until the server detects the clients crash and releases the ressources.

      2.     If the message is visible to the QueueBrowser again the QueueBrowser reports JMSXDeliveryCount = 0 and getJMSRedelivered() =false.

      3.     If after this the client connects to the server again the message then is redeliverd to the client with JMSXDeliveryCount = 1 and getJMSRedelivered() = false.


      But the content of the flags JMSXDeliveryCount and JMSRedelivered that are observed in step 3 do not differ from a first time delivery of a message.


      With JBoss Messaging 1.4.3 and 1.4.6 we have seen a similar behaviour as in HornetQ in the case of a client crash.


      JBoss MQ sets JMS_JBOSS_REDELIVERY_COUNT = 0 for fresh messages and JMS_JBOSS_REDELIVERY_COUNT = 1 for messages that are re-delivered after a client crash.




      *     Is it a bug or a feature that HornetQ 2.0.0.GA does react in this way?

      *     Are there parameters to influence the reations of HornetQ to behave an a way that is analog to JBoss MQ?