On 09/09/2009 01:58 PM, Rob Springer wrote:
Good morning everyone,
Hi Rob,
Thanks for the feedback!
I wanted to suggest a possible change to the default values in the
SubscriptionSettings object, based on recent experiences.
Our issue is with the default value of the autoAck member. When explicit
accepts are off (ACCEPT_MODE_NONE), this value is ignored. When explicit
accepts are enabled (ACCEPT_MODE_EXPLICIT), however this value IS used.
Unfortunately, the default value is 1, meaning that, even when the
developer/user requests explicit accepts via the acceptMode member,
implicit accepts will still be active unless autoAck is also overridden.
I think the confusion here comes from ambiguity on whether the accept is
'explicit' from the perspective of the server or of the client library.
I agree that is not made clear in the documentation.
ACCEPT_MODE_NODE means that the server will dequeue messages when it
delivers them to clients, without waiting for them to be accepted.
ACCEPT_MODE_EXPLICIT means that the client must send an accept in order
to signal to the server that the message can be dequeued. (These modes
and their names are taken direct from the AMQP specification).
The purpose of the 'autoAck' option is to control whether the client
library will automatically send the accept after a message is delivered
to a MessageListener (or pulled off a LocalQueue), or whether the
application will take care of doing that itself.
Now that we've figured this out (and it took us quite a while...), it's
no longer an issue for us, but I don't think this is the most intuitive
behavior, and hopefully we can prevent others from running into this
problem. I think it would make more sense for the default value of
SubscriptionSettings::autoAck to be 0, rather than 1 - if not that, then
I think there'd at least be value in more clearly calling out the
relationship between acceptMode and autoAck (rename it autoAccept)?
I agree that autoAccept would have been a better name[1]. However
renaming it would break existing applications and I myself would prefer
that we just improve the documentation to make each option clearer.
When used with MessageListeners, I think automatically sending the
accepts is a reasonable default (though I expect opinion will be divided
on that). When used with a LocalQueue I could be easily persuaded that
having the application do the accept() call itself is the more obvious
default. However, changing the default is also a backward incompatible
change which I'd rather avoid unless there is overwhelming support for it.
I've created a Jira for improving the doxygen around all this, as that
is something we can certainly address without controversy(!):
https://issues.apache.org/jira/browse/QPID-2087
--Gordon.
[1] I think the choice of name was originally intended to signal that it
would also automatically send AMQP 0-10 'completions'. However I think
it just adds to the confusion created by inadequate documentation.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscr...@qpid.apache.org
