[
https://issues.apache.org/jira/browse/QPID-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajith Attapattu updated QPID-2074:
-----------------------------------
Status: Ready To Review (was: In Progress)
> 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:[email protected]
