[
https://issues.apache.org/jira/browse/QPID-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152382#comment-13152382
]
Rajith Attapattu commented on QPID-3562:
----------------------------------------
Thanks for the feedback. I was trying to get some feel for the test cases. I
will fix the discrepancy in the java doc.
Sorry should have mentioned that this was not really to cover this specific
JIRA but rather as a starting point for a general test case for prefetch=0 and
prefetch=1. In hindsight I should have opened a separate JIRA for prefetch=1
and prefetch=0 and put it there (was a bit lazy and used this).
Also as correctly pointed out by you we need tests for synchronous and
asynchronous consumers and also test the various ACK modes including
transactions, as the behaviour does change for those different combinations. I
am hoping to get a base test case and then see if I could use that with the
different combinations. Ex client with sync and client-ack with async etc..
And as you said, perhaps it's better to have separate tests for prefetch=0 and
prefetch=1. I started with prefetch=0, but realized that I needed prefetch=1 to
get it going :)
Thanks again for your feedback/comments, as always highly appreciated.
> the 0-10 client path does not act as expected with asynchronous consumers
> using a prefetch of 1 on transacted sessions
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-3562
> URL: https://issues.apache.org/jira/browse/QPID-3562
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: 0.12
> Reporter: Robbie Gemmell
> Assignee: Robbie Gemmell
> Fix For: 0.13
>
>
> the 0-10 client path does not act as expected with asynchronous consumers
> using a prefetch of 1 on transacted sessions, as the client is able to hold a
> 2nd message during processing of a slow onMessage handler. This is because
> completions are sent to ensure credit does not dry up, allowing a
> large-than-prefetch number of messages to be consume in a given transaction.
> However, this is done prior to delivery to the client application, which
> causes the client to get sent a 2nd message by the broker.
> This should isntead occur after delivery has completed (if it is necessary:
> the client may have committed, which sends accepting completions anyway) to
> give the expected behaviour.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
