SubscriptionSettings defaults

[Rob Springer <rs...@etinternational.com>]

Good morning everyone,
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.

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)?

Thoughts?

-rob

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org

Re: SubscriptionSettings defaults

[Gordon Sim <gs...@redhat.com>]

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-subscribe@qpid.apache.org