You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org> on 2010/01/12 22:19:54 UTC
[jira] Resolved: (QPID-2074) If max_prefetch is 0 ,
FlowControllingBlockingQueue will eventually suspend the message flow
[ https://issues.apache.org/jira/browse/QPID-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rajith Attapattu resolved QPID-2074.
------------------------------------
Resolution: Fixed
The DurableSubscriptionTest which was failing due to the issue described in this JIRA have been running successfully during automated runs.
> 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