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


Mime
View raw message