You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Rob Godfrey (JIRA)" <qp...@incubator.apache.org> on 2008/05/21 12:13:55 UTC
[jira] Updated: (QPID-1084) [Java Client] Race condition suspending
channel in no-ack flow control situations
[ https://issues.apache.org/jira/browse/QPID-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Godfrey updated QPID-1084:
------------------------------
Attachment: QPID-1084.patch
Patch from M2.x branch
> [Java Client] Race condition suspending channel in no-ack flow control situations
> ---------------------------------------------------------------------------------
>
> Key: QPID-1084
> URL: https://issues.apache.org/jira/browse/QPID-1084
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: M2, M2.1, M3
> Reporter: Rob Godfrey
> Assignee: Rob Godfrey
> Attachments: QPID-1084.patch
>
>
> When operating in no-ack mode the 0-8/0-9 client session uses a FlowControllingBlockingQueue with a threshold listener to attempt to flow control the channel when too many messages build up.
> This code has a built in race condition:
> new FlowControllingBlockingQueue.ThresholdListener()
> {
> public void aboveThreshold(int currentValue)
> {
> _logger.debug(
> "Above threshold(" + _defaultPrefetchHighMark
> + ") so suspending channel. Current value is " + currentValue);
> new Thread(new SuspenderRunner(true)).start();
> }
> public void underThreshold(int currentValue)
> {
> _logger.debug(
> "Below threshold(" + _defaultPrefetchLowMark
> + ") so unsuspending channel. Current value is " + currentValue);
> new Thread(new SuspenderRunner(false)).start();
> }
> });
> A call to aboveThreshold which is quickly followed by a call to underThreshold may result in the SuspenRunner threads executing in the opposite order to that which was desired.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.