2 Replies Latest reply on Sep 17, 2013 1:41 PM by shannon.h

    Acknowledging JMS messages using the Core API?

    shannon.h

      Greetings!

       

      I have a JMS consumer reading messages from a queue using client acknowledge mode. However, I would like more granular control over message acknowledgement. Is it possible to use the Core API to individually acknowledge JMS messages? Or is that a recipe for disaster? Should I just bite the bullet and rewrite the JMS producer and consumer using the Core API?

       

      My attempts so far have proven problematic. In my JMS consumer, I was successful in reading the message from the queue, casting it to HornetQMessage, and calling getCoreMessage().individualAcknowledge(). This sent the ack to the server, but the server wrote the following complaint to the log:

       

      java.lang.IllegalStateException: Cannot find ref to ack ###

       

      Furthermore, the messages remain in the queue. However, it struck me as odd that after consuming the message from the queue, the contents of the messages are empty. Everything works as expected if I use the acknowledge() method on the JMS message interface.

       

      I am using HornetQ 2.3.1.Final.

       

      Any advice would be appreciated!

       

      Thanks,

      Shannon

        • 1. Re: Acknowledging JMS messages using the Core API?
          clebert.suconic

          We have introduced the feature of individual ACK even through JMS. if you use HornetQJMSConstants.INDIVIDUAL_ACKNOWLEDGE on the session type, every ACK will be done individually.

           

           

          You could also do the way you liked through core API.

           

           

          Just be careful with too many messages on the buffer and having to do a big scan to find messages. but if you are dealing with regular buffer sizes and set flow control to default values, it should be alright.

          • 2. Re: Acknowledging JMS messages using the Core API?
            shannon.h

            Thank you for the response! I decided to use the core API for both the producer and consumer, but it is good to know about the JMS option going forward.

             

            I will keep the warning in mind regarding buffer sizes and flow control, as we may encounter bursts of high volume.

             

            Thanks,

            Shannon