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