On 11/17/2011 03:01 PM, Robbie Gemmell wrote:
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).
Excellent, that simplifies everything. Thanks for the info!
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
