qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Godfrey (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Updated: (QPID-1084) [Java Client] Race condition suspending channel in no-ack flow control situations
Date Wed, 21 May 2008 10:13:55 GMT

     [ 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.


Mime
View raw message