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