Hello Tim and Clebert,

thank you for spending your valuable time and your quick response!

1.     Yes, Tim, the parameter

persist-delivery-count-before-delivery

has been set to true, but this does not influence the test result in step 3 above. The

• fresh and
  
• redelivered message
  

have both the parameters

• JMSXDeliveryCount = 1
• getJMSRedelivered() = false.

2.     The tests have shown that the connection TTL does influence the time until the ressources are released by the server (as described in the user manual) and therefore unitl the message is visible to the QueueBrowser again.

Thank you Clebert for pointing me to this part of the user manual!

This parameter is important for us because the messages in the queue initiate the processing of catalogues on a cluster of service units that can last for hours.

But the present focus while migrating the application that runs for about five years is to prevent the reprocessing of jobs that have caused a system error on the service unit and crashed the JVM. In the old system we move those messages that would be redelivered into the  DLQ by a MDB.

We have implemented a reconnection feature in the client in the case of lost connections (and use a message listener in the productive client application). But crashed JVMs must be restarted by the system administrator.

3.     Meanwhile I  have had a closer look to the JMS 1.1 specification. Under "4.10 Reliability" it does state on page 72:

"Unacknowledged messages redelivered due to system failure must have the JMSRedelivered message header field set by the JMS provider."

On the first view there may be a discrepancy between the test result noted in this email under point 1 and this requirement in the JMS specification.

Greetings

Andreas

Hello Tim,

thank you for your interest in this point! The simple test class is added to this posting.

As mentioned in the starting message of this thread the test covers the case that the - client - crashes.

As far as I can see it the QueueBrowser does not matter. Therefore the test class does not contain it. It just has been used to see when the TTL is over and the message is available on the queue again. (Our application has a graphical utility that browses the queues.)

Greetings

Andreas

Hello Tim,

thank you for your really fast reaction to this point!

I hope that HornetQ 2.1.0.GA will come soon and within the time frame of our projekt, so that our project management can be convinced to migrate to it!

Greetings

Andreas

Hello Tim,

yes, your fix has been tested in our application using the release 2.1.1.Final.

Best regards,

Andreas