[
https://issues.apache.org/jira/browse/QPID-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868781#action_12868781
]
Robbie Gemmell commented on QPID-2559:
--------------------------------------
>Hi Martin,
>I am a little confused about your comment - "Not sure if you noticed your
>actually using transacted sessions on your consumers." .
>The consumer session is using AUTO_ACK and now both consumers are created off
>the same session.
I believe Martin would have been referencing the fact that the test you are
modifying uses consumer sessions which are created with the code below, which
has transacted = true and thereby ignores the acknowledgeMode parameter as per
the JMS spec:
connection.createSession(true, Session.AUTO_ACKNOWLEDGE);
> 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
