[
https://issues.apache.org/jira/browse/QPID-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868834#action_12868834
]
Rajith Attapattu commented on QPID-2559:
----------------------------------------
>I think I need to investigate why the original test didn't work when the ack
>mode was transacted.
>The credits should not have been replenished unless session.commit() was
>called.
I found the reason. If the session is transacted, we use the
"addDeliveredMessage" method in AMQSession_0_10.java to record the non
committed messages.
However we use the following heuristic to send completions to replenish credits.
if (_connection.getMaxPrefetch() == 1 ||
_connection.getMaxPrefetch() != 0 && _txSize %
(_connection.getMaxPrefetch() / 2) == 0)
{
// send completed so consumer credits don't dry up
messageAcknowledge(_txRangeSet, false);
}
Since we use a prefetch of just 2 messages, we easily triggered the condition,
hence we acked after just consuming one message.
That is the reason why consumerA got the other two messages as well (even
though the session wasn't committed) before consumerB who was on a different
session was able to get those two messages.
> 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
>
> Attachments: QPID-2559.test
>
>
> 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-subscr...@qpid.apache.org
