+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
