activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From artnaseef <...@amlinv.com>
Subject Re: Need Help With A JMS Exception
Date Fri, 02 Sep 2016 04:35:56 GMT
The broker and client negotiate the version of the OpenWire protocol when
the client connects.  If the client sends a version of an ack that the
broker doesn't support, something is really wrong.

Are all the brokers running the same version of ActiveMQ?


On Thu, Sep 1, 2016 at 12:52 PM, Michael.CTR.Tarullo [via ActiveMQ] <
ml-node+s2283324n4716079h97@n4.nabble.com> wrote:

> I am not certain about this but I think the version mismatch was
> discovered because the ackType in the exception was = 6, and someone (not
> me  because at that time I was not involved with the project) noticed that
> v5.5.1 did not support ackType = 6, i.e. the max ackType for v5.5.1 is 5.
>
> I don't know if the client was using failover transport.  I'm not sure if
> this was ever investigated but I can try to find out.
>
> Thanks for your thoughts.
>
> Michael Tarullo
> Contractor (Engility Corp)
> Software Engineer
> FAA WJH Technical Center
> (609)485-5294
>
>
> -----Original Message-----
> From: artnaseef [mailto:[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4716079&i=0>]
> Sent: Thursday, September 01, 2016 12:05 PM
> To: [hidden email] <http:///user/SendEmail.jtp?type=node&node=4716079&i=1>
> Subject: Re: Need Help With A JMS Exception
>
> A couple of thoughts on this front.
>
> First, how was the conclusion of different client versions made?  I'm
> curious because I can't think of any way that should be an issue.
>
> Second, is the consumer using the failover transport?
>
> This JMS Exception can happen normally without indicating a problem,
> especially with the failover transport, as the consumer may then send an
> acknowledgement to the broker after it has already received another
> acknowledgement for the same message.  Or, with Topics, the rebuilt
> subscription may not have the message - I'm not sure how the failover
> transport handles non-durable Topic subscriptions.  My suspicion is that
> the new subscription, after failover, will start fresh, with none of the
> old messages.  So, if the consumer then proceeds to send an acknowledgement
> for the message, the broker won't be able to match the message.
>
>
>
> On Thu, Sep 1, 2016 at 11:13 AM, Michael.CTR.Tarullo [via ActiveMQ] <
> [hidden email] <http:///user/SendEmail.jtp?type=node&node=4716079&i=2>>
> wrote:
>
> > 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:[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4716062&i=0>]
> > Sent: Thursday, September 01, 2016 10:58 AM
> > To: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4716062&i=1>
> > 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, <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4716062&i=2>> 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
> > >>
> > >>
> >
> >
> >
> > ------------------------------
> > If you reply to this email, your message will be added to the
> > discussion
> > below:
> > http://activemq.2283324.n4.nabble.com/Need-Help-With-A-JMS-Exception-
> > tp4716045p4716062.html
> > To start a new topic under ActiveMQ - User, email
> > [hidden email] <http:///user/SendEmail.jtp?type=node&node=4716079&i=3>
> > To unsubscribe from ActiveMQ - User, click here
> > <http://activemq.2283324.n4.nabble.com/template/NamlServlet.jtp?macro=
> > unsubscribe_by_code&node=2341805&code=YXJ0QGFtbGludi5jb218MjM0MTgwNXwy
> > MDc3NjQwODU5>
> > .
> > NAML
> > <http://activemq.2283324.n4.nabble.com/template/NamlServlet.jtp?macro=
> > macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.na
> > mespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabbl
> > e.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nab
> > ble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_ema
> > il%21nabble%3Aemail.naml>
> >
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Need-Help-With-A-JMS-Exception-tp4716045p4716067.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://activemq.2283324.n4.nabble.com/Need-Help-With-A-JMS-Exception-
> tp4716045p4716079.html
> To start a new topic under ActiveMQ - User, email
> ml-node+s2283324n2341805h3@n4.nabble.com
> To unsubscribe from ActiveMQ - User, click here
> <http://activemq.2283324.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=2341805&code=YXJ0QGFtbGludi5jb218MjM0MTgwNXwyMDc3NjQwODU5>
> .
> NAML
> <http://activemq.2283324.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://activemq.2283324.n4.nabble.com/Need-Help-With-A-JMS-Exception-tp4716045p4716096.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message