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/05/08 03:50:47 UTC
[jira] Updated: (QPID-2559) When a subscription is created, message
credits should only be set if the dispatcher is not null.
[ https://issues.apache.org/jira/browse/QPID-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rajith Attapattu updated QPID-2559:
-----------------------------------
Summary: When a subscription is created, message credits should only be set if the dispatcher is not null. (was: When a subscription is created, message credits should only be set if the session is active.)
Description:
When a subscription is created, message credits should only be set if the dispatcher is not null.
If the dispatcher is null, the session is suspended temporarily until a dispatcher is created.
And then when the session is unsuspended, message credits will be set again, resulting in granting more credits than intended.
Please note in order for this error condition to happen the dispatcher should be null and the broker should have enough messages.
If the connection is not started and the message consumer is the very first to be created for that session, then the dispatcher thread for that session is null.
Steps To Reproduce
----------------------------
1. create connection, but not start it
1. create a session with client ack
2. send 20 messages to a queue
3. create receiver with capacity (prefetch) as 10.
4. start connection.
5. receive 10 messages
Look at the client and broker logs and observe that the broker sends more messages than needed.
Expected Result.
------------------------
At any given time we should only receive n messages, where n == maxprefetch (capacity as defined for the destination)
Actual Result
-------------------
For the above conditions, we get double than what we want (provided the broker has enough messages on the queue).
was:
When a subscription is created, message credits should only be set if the session is active.
If not when the session is unsuspended message credits will be set again, resulting in granting more credits than intended.
Steps To Reproduce
----------------------------
1. create a session with client ack
2. send 20 messages to a queue
3. create receiver with capacity (prefetch) as 10.
4. receive 10 messages
5. try to receive the 11th message
The 11th message should be null, if it isn't it means that we have received more than 10 messages.
We should only receive the next set of messages if we ack the previous batch.
Ex. If we acked the 5th message, then we should get another 5.
Expected Result.
------------------------
At any given time we should only receive n messages, where n == maxprefetch (capacity as defined for the destination)
Actual Result
-------------------
For the above conditions, we get double than what we want (provided the broker has enough messages on the queue).
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> -------------------------------------------------------------------------------------------------
>
> Key: QPID-2559
> URL: https://issues.apache.org/jira/browse/QPID-2559
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: 0.6
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Fix For: 0.7
>
>
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> If the dispatcher is null, the session is suspended temporarily until a dispatcher is created.
> And then when the session is unsuspended, message credits will be set again, resulting in granting more credits than intended.
> Please note in order for this error condition to happen the dispatcher should be null and the broker should have enough messages.
> If the connection is not started and the message consumer is the very first to be created for that session, then the dispatcher thread for that session is null.
> Steps To Reproduce
> ----------------------------
> 1. create connection, but not start it
> 1. create a session with client ack
> 2. send 20 messages to a queue
> 3. create receiver with capacity (prefetch) as 10.
> 4. start connection.
> 5. receive 10 messages
> Look at the client and broker logs and observe that the broker sends more messages than needed.
> Expected Result.
> ------------------------
> At any given time we should only receive n messages, where n == maxprefetch (capacity as defined for the destination)
> Actual Result
> -------------------
> For the above conditions, we get double than what we want (provided the broker has enough messages on 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