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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
