qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Resolved: (QPID-2074) If max_prefetch is 0 , FlowControllingBlockingQueue will eventually suspend the message flow
Date Tue, 12 Jan 2010 21:19:54 GMT

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

View raw message