qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marnie McCormack (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Reopened: (QPID-1084) [Java Client] Race condition suspending channel in no-ack flow control situations
Date Thu, 18 Sep 2008 15:56:44 GMT

     [ https://issues.apache.org/jira/browse/QPID-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Marnie McCormack reopened QPID-1084:

Feedback from external review:

Took a look at the change it solves some of the issues.

Can still spawn threads as rapidly as the threshold is oscilatted over, so still an issue
of spawning threads.
It also does not conflate changes of state, so the work in suspendChannel method is done -
however many threads are spawned. 

At least now you can't get to the wrong state which is much better than it was. I would have
expected a change in suspendChannel as well with a check if the target state equalled the
current state it does nothing to avoid the overhead of doing uneeded work. 

> [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
> This code has a built in race condition:
> new FlowControllingBlockingQueue.ThresholdListener()
>                                                      {
>                                                          public void aboveThreshold(int
>                                                          {
>                                                                  _logger.debug(
>                                                                          "Above threshold("
+ _defaultPrefetchHighMark
>                                                                          + ") so suspending
channel. Current value is " + currentValue);
>                                                                  new Thread(new SuspenderRunner(true)).start();
>                                                          }
>                                                          public void underThreshold(int
>                                                          {
>                                                                  _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.

View raw message