Thanks Matt. And yes I was aware of the behavior of CLIENT_ACK, although when I started this research I was not. Before this I was under the impression that it was a single message ack.
Michael Tarullo Contractor (Engility Corp) Software Engineer FAA WJH Technical Center (609)485-5294 -----Original Message----- From: Matt Pavlovich [mailto:mattr...@gmail.com] Sent: Thursday, September 01, 2016 10:58 AM To: users@activemq.apache.org Subject: Re: Need Help With A JMS Exception +1 Agree that debugging it is the only surefire way to understand what is going on. On a side note-- CLIENT_ACKNOWLEDGE is kludgy of sorts. Be sure to understand that it acknowledges the current message and _all_ previous messages. It isn't an individual message acknowledgement as most people are hoping. To get that, you need to use ActiveMQ's extension ActiveMQSession.INDIVIDUAL_ACKNOWLEDGE or go full blown TRANSACTED. All JMS providers have this "extended" ack mode and there is a JMS feat request to make INDIVIDUAL_ACKNOWLEDGE a standardized thing: Vote here: https://java.net/jira/browse/JMS_SPEC-95 On 9/1/16 7:47 AM, Tim Bain wrote: > Since you have the 5.5.1 source code, I recommend you attach a debugger to > the broker process and set a breakpoint on the > TopicSubscription.acknowledge() method; the stack will tell you how you got > there. Setting breakpoints on the broker can lead to instability and may > force you to restart it (plus you have to restart it to enable the debug > port and again to disable it, and it's a security vulnerability while it's > open), so do this in a dev/test environment, not a production one. > > You should not expect that there would be a call chain between the two > methods you referenced. One is executed on the client and one is executed > on the broker, so between the two there is the creation, transmission, and > handling of the acknowledgement message. > > Tim > > On Aug 31, 2016 4:15 PM, <michael.ctr.taru...@faa.gov> wrote: > >> We had a rather unique situation some time ago where our message broker >> log was recording the JMSException for an Invalid acknowledgement. >> >> We traced it to the fact that the consumer of the message was using a more >> recent version of ActiveMQ than our message broker was running (i.e. >> message broker was v5.5.1 and the consumer was >v5.5.1). >> >> We would like to recreate this error in one of our test environments so >> that we can learn more about it. >> >> It appears that the exception was related to a consumer acknowledging a >> message. We determined this from observing that the specific exception >> that was thrown appears to originate in only one place, that is the >> acknowledge() function of the TopicSubscription class. >> >> I have configured an environment with a v5.5.1 message broker and a >> consumer and producer compiled with v5.11.0 of ActiveMQ. The producer >> sends messages to a topic and the consumer receives these messages and then >> acknowledges those messages. The session was configured for client >> acknowledgement. Under these conditions I could not reproduce the >> exception described above. >> >> I tried looking through the source code for the acknowledge() function of >> the ActiveMQMessage class to see if I could determine how my consumer call >> to acknowkedge() landed on the TopicSubscription acknowledge(), but have >> been unable to make a connection between the acknowledge() function in >> ActiveMQMessage and TopicSubscription even after following the calls >> starting with the call to ActiveMQMessage acknowledge(). >> >> Can you offer any explanation as to why I am unable to trace the functions >> calls to TopicSubscription acknowledge? And more importantly, can you >> offer any advice on how I might recreate the exception condition described >> here? >> >> Thanks, >> Mike >> >> Michael Tarullo >> Contractor (Engility Corp) >> Software Engineer >> FAA WJH Technical Center >> (609)485-5294 >> >>
