You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by jonathans2 <jo...@gmail.com> on 2014/10/10 12:35:58 UTC
Problems using CLIENT_ACKNOWLEDGE with
qpid-amqp-1-0-client-jms-0.28 and ActiveMQ
Hi, I'm trying to use the JMS AMQP1.0 client with activemq. In my
application, I want to be able to effectively NACK a message in certain
error conditions, so it'll get redelivered. To do this, I'm creating a
session with Session.CLIENT_ACKNOWLEDGE, and in my listener calling
message.acknowledge() on success. On failure, I'm calling session.recover(),
as my reading of the jms spec suggests this is the only way to ensure the
message gets redelivered, otherwise a subsequent call to message.acknowledge
on a different message will implicitly acknowledge the previous message.
However, after calling session.recover(), I stop seeing any messages on that
queue at all. If I restart my application, then they all come through and
are processed.
Am I doing something wrong? Is this a bug in the amqp-1-0-jms library?
Should I abandon my attempts to use that library and use proton-j directly
instead (despite a fairly terminal lack of documentation as far as I can
see).
Any help/advice appreciated.
Jonathan
--
View this message in context: http://qpid.2158936.n2.nabble.com/Problems-using-CLIENT-ACKNOWLEDGE-with-qpid-amqp-1-0-client-jms-0-28-and-ActiveMQ-tp7614874.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Problems using CLIENT_ACKNOWLEDGE with qpid-amqp-1-0-client-jms-0.28
and ActiveMQ
Posted by Rob Godfrey <ro...@gmail.com>.
Looking at the code, the connection level lock is going to be held
throughout the time spent in onMessage() so at the moment you can't
implement backoff yourself within a single connection. In the multiple
connection case obviously you can add sleep()s yourself. The
recover/replay logic is actually entirely client side so the protocol
doesn't actually come into play.
When we were designing the protocol we did discuss how this sort of case (a
message which cannot be processed due to some transient external condition)
should be handled - the thinking was that for cases where the "transient"
condition might be long lived this could be handled by "annotating" the
message and using filters to control the flow of such annotated messages.
Unfortunately I don't think anyone has tried to implement that yet, and
even if they did - I'm not sure how that functionality could be addressed
through the JMS API (Robbie: one for your mapping document - how do we do
custom outcomes?)
-- Rob
On 10 October 2014 17:25, jonathans2 <jo...@gmail.com> wrote:
> Yes, definitely need some backoff, but in the case where each session is
> truly independent, this could be done by just sticking a sleep in the
> onMessage before calling session.recover(). Maybe not ideal, but would
> work.
> I don't know amqp well enough to know whether it's something that could be
> handled within the protocol rather than by client side coding.
>
> Jonathan
>
>
>
>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/Problems-using-CLIENT-ACKNOWLEDGE-with-qpid-amqp-1-0-client-jms-0-28-and-ActiveMQ-tp7614874p7615089.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Problems using CLIENT_ACKNOWLEDGE with
qpid-amqp-1-0-client-jms-0.28 and ActiveMQ
Posted by jonathans2 <jo...@gmail.com>.
Yes, definitely need some backoff, but in the case where each session is
truly independent, this could be done by just sticking a sleep in the
onMessage before calling session.recover(). Maybe not ideal, but would work.
I don't know amqp well enough to know whether it's something that could be
handled within the protocol rather than by client side coding.
Jonathan
--
View this message in context: http://qpid.2158936.n2.nabble.com/Problems-using-CLIENT-ACKNOWLEDGE-with-qpid-amqp-1-0-client-jms-0-28-and-ActiveMQ-tp7614874p7615089.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Problems using CLIENT_ACKNOWLEDGE with qpid-amqp-1-0-client-jms-0.28
and ActiveMQ
Posted by Rob Godfrey <ro...@gmail.com>.
If I get a chance, I'll have a look at how the locking is working over the
weekend. It seems from your description of your use case that you'd really
want to have some sort of back-off in the recover/replay behaviour anyway,
because each of your threads are going to be busy waiting until your error
conditions clear... not sure how long you expect that to take normally, but
that doesn't sound like a particularly desirable outcome.
-- Rob
On 10 October 2014 16:48, jonathans2 <jo...@gmail.com> wrote:
> Okay, that's exactly what is happening yes, makes sense.
> If I have two completely different connections it works as desired - which
> I
> guess means I end up needing a separate connection for every listener.
>
> Thanks again,
>
> Jonathan
>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/Problems-using-CLIENT-ACKNOWLEDGE-with-qpid-amqp-1-0-client-jms-0-28-and-ActiveMQ-tp7614874p7615077.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Problems using CLIENT_ACKNOWLEDGE with
qpid-amqp-1-0-client-jms-0.28 and ActiveMQ
Posted by jonathans2 <jo...@gmail.com>.
Okay, that's exactly what is happening yes, makes sense.
If I have two completely different connections it works as desired - which I
guess means I end up needing a separate connection for every listener.
Thanks again,
Jonathan
--
View this message in context: http://qpid.2158936.n2.nabble.com/Problems-using-CLIENT-ACKNOWLEDGE-with-qpid-amqp-1-0-client-jms-0-28-and-ActiveMQ-tp7614874p7615077.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Problems using CLIENT_ACKNOWLEDGE with qpid-amqp-1-0-client-jms-0.28
and ActiveMQ
Posted by Rob Godfrey <ro...@gmail.com>.
That's probably an artefact of how the locking in the client works ... In
practice a connection is tied to a single TCP/IP connection and thus there
is of necessity some connection level locking. Thus two sessions on the
same connection are not really independent. The way recover() works is to
immediately play back all the messages that have been previously
delivered... I'm guessing that this is (in your scenario) effectively
turning into a busy loop and is either always holding the connection level
lock or else constantly letting go and then reacquiring the connection
level lock (I'd need to spend a bit of time looking at the code to discover
which one of those scenarios is actually true).
If you move to having your sessions on two different connections does your
problem resolve itself?
-- Rob
On 10 October 2014 15:25, jonathans2 <jo...@gmail.com> wrote:
> Thanks, I had just downloaded trunk and got it to build myself anyway.
>
> That does seem to fix it - on calling session.recover() the unacknowledged
> message gets redelivered as expected.
>
> I am seeing now other oddness as a result. I have two asynchronous
> messagelisteners set up. They're created using different session objects,
> which I thought would mean they run independently on different threads, and
> the second one is using AUTO_ACKNOWLEDGE rather than CLIENT_ACKNOWLEDGE.
> However while my first messagelistener is sitting in a loop trying to
> process a message, failing it, calling session.recover() etc, nothing is
> being received by my other messagelistener even though messages are being
> sent to it. Once the error condition clears and I start acknowledging
> messages on my first messagelistener, the messages start coming through on
> the other one.
>
> Have I misunderstood something?
>
> Thanks again,
> Jonathan
>
>
>
>
>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/Problems-using-CLIENT-ACKNOWLEDGE-with-qpid-amqp-1-0-client-jms-0-28-and-ActiveMQ-tp7614874p7615066.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Problems using CLIENT_ACKNOWLEDGE with
qpid-amqp-1-0-client-jms-0.28 and ActiveMQ
Posted by jonathans2 <jo...@gmail.com>.
Thanks, I had just downloaded trunk and got it to build myself anyway.
That does seem to fix it - on calling session.recover() the unacknowledged
message gets redelivered as expected.
I am seeing now other oddness as a result. I have two asynchronous
messagelisteners set up. They're created using different session objects,
which I thought would mean they run independently on different threads, and
the second one is using AUTO_ACKNOWLEDGE rather than CLIENT_ACKNOWLEDGE.
However while my first messagelistener is sitting in a loop trying to
process a message, failing it, calling session.recover() etc, nothing is
being received by my other messagelistener even though messages are being
sent to it. Once the error condition clears and I start acknowledging
messages on my first messagelistener, the messages start coming through on
the other one.
Have I misunderstood something?
Thanks again,
Jonathan
--
View this message in context: http://qpid.2158936.n2.nabble.com/Problems-using-CLIENT-ACKNOWLEDGE-with-qpid-amqp-1-0-client-jms-0-28-and-ActiveMQ-tp7614874p7615066.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Problems using CLIENT_ACKNOWLEDGE with qpid-amqp-1-0-client-jms-0.28
and ActiveMQ
Posted by Robbie Gemmell <ro...@gmail.com>.
On 10 October 2014 13:44, Rob Godfrey <ro...@gmail.com> wrote:
> Are you able to test by building the client yourself from the current trunk
> sources?
>
I forced the nightly build job to run early, you should find the client
archive here:
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Artefact-Release/lastSuccessfulBuild/artifact/
Snapshots are also published at:
https://repository.apache.org/content/repositories/snapshots/
>
> Prefetch shouldn't have any effect, it's just that a prior fix to allow for
> proper recover() with client ack hadn't properly taken into account the
> onMessage() case. Hopefully the small change I applied here:
> https://svn.apache.org/viewvc?view=revision&revision=r1630766 should solve
> that issue. As an aside, proton-j itself doesn't provide any direct
> asynchronous API, so you'd have to build one... and since I think the bug
> in the JMS client is restricted to the async case (and receive should work
> fine) I don't think that would help you. However if you do plan to use the
> JMS client, I'd strongly recommend picking up the latest release (0.30) as
> that has a number of bug fixes in it (although sadly not one for the
> particular bug you have encountered :-( ... that fix will be going in to
> 0.32).
>
> -- Rob
>
>
> On 10 October 2014 13:48, jonathans2 <jo...@gmail.com> wrote:
>
> > Hi,
> > Yes, this was using an asychronous messagelistener. If relevant, I'm also
> > using the fairly special case of having prefetch=1, not sure if that has
> > any
> > impact on the bug.
> >
> > Thanks for the quick attention!
> >
> > Jonathan
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://qpid.2158936.n2.nabble.com/Problems-using-CLIENT-ACKNOWLEDGE-with-qpid-amqp-1-0-client-jms-0-28-and-ActiveMQ-tp7614874p7614887.html
> > Sent from the Apache Qpid users mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
Re: Problems using CLIENT_ACKNOWLEDGE with qpid-amqp-1-0-client-jms-0.28
and ActiveMQ
Posted by Rob Godfrey <ro...@gmail.com>.
Are you able to test by building the client yourself from the current trunk
sources?
Prefetch shouldn't have any effect, it's just that a prior fix to allow for
proper recover() with client ack hadn't properly taken into account the
onMessage() case. Hopefully the small change I applied here:
https://svn.apache.org/viewvc?view=revision&revision=r1630766 should solve
that issue. As an aside, proton-j itself doesn't provide any direct
asynchronous API, so you'd have to build one... and since I think the bug
in the JMS client is restricted to the async case (and receive should work
fine) I don't think that would help you. However if you do plan to use the
JMS client, I'd strongly recommend picking up the latest release (0.30) as
that has a number of bug fixes in it (although sadly not one for the
particular bug you have encountered :-( ... that fix will be going in to
0.32).
-- Rob
On 10 October 2014 13:48, jonathans2 <jo...@gmail.com> wrote:
> Hi,
> Yes, this was using an asychronous messagelistener. If relevant, I'm also
> using the fairly special case of having prefetch=1, not sure if that has
> any
> impact on the bug.
>
> Thanks for the quick attention!
>
> Jonathan
>
>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/Problems-using-CLIENT-ACKNOWLEDGE-with-qpid-amqp-1-0-client-jms-0-28-and-ActiveMQ-tp7614874p7614887.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Problems using CLIENT_ACKNOWLEDGE with
qpid-amqp-1-0-client-jms-0.28 and ActiveMQ
Posted by jonathans2 <jo...@gmail.com>.
Hi,
Yes, this was using an asychronous messagelistener. If relevant, I'm also
using the fairly special case of having prefetch=1, not sure if that has any
impact on the bug.
Thanks for the quick attention!
Jonathan
--
View this message in context: http://qpid.2158936.n2.nabble.com/Problems-using-CLIENT-ACKNOWLEDGE-with-qpid-amqp-1-0-client-jms-0-28-and-ActiveMQ-tp7614874p7614887.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Problems using CLIENT_ACKNOWLEDGE with qpid-amqp-1-0-client-jms-0.28
and ActiveMQ
Posted by Rob Godfrey <ro...@gmail.com>.
Hi Jonathan,
am I correct in thinking you are using recover() in a session which uses
MessageListener asynchronous message receipt (rather than a synchronous
consumer.receive() style)? From a quick look at the code it does seem like
there is a bug there (using consumer.receive() should work with recover
though).
I've raised an issue in JIRA :
https://issues.apache.org/jira/browse/QPID-6141 and I've made a change to
the trunk codebase which I believe will fix this problem.
Apologies for the bug,
Rob
On 10 October 2014 12:35, jonathans2 <jo...@gmail.com> wrote:
> Hi, I'm trying to use the JMS AMQP1.0 client with activemq. In my
> application, I want to be able to effectively NACK a message in certain
> error conditions, so it'll get redelivered. To do this, I'm creating a
> session with Session.CLIENT_ACKNOWLEDGE, and in my listener calling
> message.acknowledge() on success. On failure, I'm calling
> session.recover(),
> as my reading of the jms spec suggests this is the only way to ensure the
> message gets redelivered, otherwise a subsequent call to
> message.acknowledge
> on a different message will implicitly acknowledge the previous message.
>
> However, after calling session.recover(), I stop seeing any messages on
> that
> queue at all. If I restart my application, then they all come through and
> are processed.
>
> Am I doing something wrong? Is this a bug in the amqp-1-0-jms library?
> Should I abandon my attempts to use that library and use proton-j directly
> instead (despite a fairly terminal lack of documentation as far as I can
> see).
>
> Any help/advice appreciated.
>
> Jonathan
>
>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/Problems-using-CLIENT-ACKNOWLEDGE-with-qpid-amqp-1-0-client-jms-0-28-and-ActiveMQ-tp7614874.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>