On 17 November 2011 14:37, Gordon Sim <[email protected]> wrote: > On 11/17/2011 12:47 PM, Keith W wrote: >> >> QPID-2703 - Transaction rollback/recover does not restore consumer credit. >> >> There are two separate aspects to this change. A Broker side bug >> affecting 0-8..0-9-1 and a client side issue affecting 0-10. In the >> former case the Broker needs to restore credit when messages are >> requeued, and the latter, the client was failing to complete the >> message transfer commands for the messages it was releasing resulting >> in a failure to restore credit. There is no way for the user to >> workaround this issue - in both cases the consumer starves after >> rolling-back/recovering >> <pre-fetch sized> number of messages. > > Does this need to be tied to a fix for QPID-3629? I.e. if the fix for the > JMS client goes in, but the c++ broker is not fixed would that result in a > regression from previous versions? >
No, they do not need to be tied. We have added rollback+recover tests that show the behaviour is correct against both brokers, and so fixing the client (as we already have on trunk) has no ill effects despite the credit window issues remaining (which only manifests itself with a misbehaving client, such as the python test we attached to QPID-3629). Robbie. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
