[
https://issues.apache.org/jira/browse/QPID-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-2703:
-----------------------------
Description:
When a transaction rollback/recover occurs on the 0-8/0-9/0-91 code path the
messages are put back on to the queue but the subscriber is not credited for
them. This can be seen with a small prefetch. The credit is lost and the client
starves. Adding a restoreCredit call in the message release will address this
issue.
The same issue exists in 0-10 code path but for *different* reasons. On 0-10,
a client is required to complete commands. The Java client currently fails to
complete the message.transfer commands that correspond to those messages that
must be returned to the Broker due to the rollback/recover and for this reason
the Brokers are failing to recredit. This problem is evident when using the
Java Broker, but is masked when using the CPP Broker (by a credit window issue
that results in the Broker expanding credit window beyond the requested limit).
was:
When a transaction rollback/recover occurs on the 0-8/0-9/0-91 code path the
messages are put back on to the queue but the subscriber is not credited for
them. This can be seen with a small prefetch. The credit is lost and the client
starves. Adding a restoreCredit call in the message release will address this
issue.
The same issue exists in 0-10 code path but for *different* reasons. On 0-10,
a client is required to complete commands. The Java client currently fails to
complete the message.transfer commands that correspond to those messages that
must be returned to the Broker due to the rollback/recover and for this reason
the Brokers are failing to recredit.
> Transaction Rollback/Recover does not restore consumer credit
> -------------------------------------------------------------
>
> Key: QPID-2703
> URL: https://issues.apache.org/jira/browse/QPID-2703
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.15
> Reporter: Martin Ritchie
> Assignee: Keith Wall
>
> When a transaction rollback/recover occurs on the 0-8/0-9/0-91 code path the
> messages are put back on to the queue but the subscriber is not credited for
> them. This can be seen with a small prefetch. The credit is lost and the
> client starves. Adding a restoreCredit call in the message release will
> address this issue.
> The same issue exists in 0-10 code path but for *different* reasons. On
> 0-10, a client is required to complete commands. The Java client currently
> fails to complete the message.transfer commands that correspond to those
> messages that must be returned to the Broker due to the rollback/recover and
> for this reason the Brokers are failing to recredit. This problem is
> evident when using the Java Broker, but is masked when using the CPP Broker
> (by a credit window issue that results in the Broker expanding credit window
> beyond the requested limit).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
