[jira] Commented: (QPID-2074) If max_prefetch is 0 , FlowControllingBlockingQueue will eventually suspend the message flow

["Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>]

    [ https://issues.apache.org/jira/browse/QPID-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12746942#action_12746942 ] 

Rajith Attapattu commented on QPID-2074:
----------------------------------------

I committed a fix in rev 807292 in Qpid trunk.

I added a flag to disable flow control when max prefetch is zero. This will also prevent unnecessary suspend/resume actions (and hence extra threads being spawned) when the non meaningful thresholds (for the above case) are passed.
I also think that adjusting the count and putting the message into the queue should be an atomic operation. This means notifying the listener will also need to be squeezed inside the same sync block. Another point to note is that this is redundant in the 0-10 code path as we have protocol level flow control. Since a more complete overhaul is needed in this area, for the time being I have only done the bare minimum.

I also added a timeout for all sync receives in the DurableSubscriptionTest. This will prevent the whole test suite from hanging if messages don't arrive as expected. The above test was hanging due to the problem described in the JIRA.

> If max_prefetch is 0 , FlowControllingBlockingQueue will eventually suspend the message flow
> --------------------------------------------------------------------------------------------
>
>                 Key: QPID-2074
>                 URL: https://issues.apache.org/jira/browse/QPID-2074
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Client
>    Affects Versions: 0.5
>            Reporter: Rajith Attapattu
>            Assignee: Rajith Attapattu
>             Fix For: 0.6
>
>
> The FlowControllingBlockingQueue will suspend and unsuspend the message flow, on reaching the high and low watermarks respectively. 
> In 0-10 code path, if the max_prefetch is set to 0, the above class could irrevocably suspend the message flow under the following circumstances.
> 1. The _count starts at zero and we receive a message. The _count is incremented to 1 (the high water mark check passes as high-watermark is zero).
> 2. If the message is taken from the queue the count will be reduced to zero (fails the low water mark check) .
> 3. The client waits for the next message inside take() and gets notified once a message is put on the queue inside the add(). However the code block that decrements _count inside the take() method could execute before the code block that increments _count inside the take()
> 4. If the above happened the decrement (in take()) will bring _count to -1 and the increment (in add()) will bring the _count to zero, hence will fail the high water mark check. This will trigger a session suspend which results in sending a message-stop in 0-10 code path.
> 5. So even if there are more messages on the brokers queue, and the client calling receive() and sending 1 message credit, the broker will not send any messages to the client due to lack of byte credits as all message/byte credits was wiped out by the previous message-stop. This will make the JMS client block on receive() even when there is messages in the queue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org