On 01/17/2011 03:06 PM, Carl Trieloff wrote:
On 01/17/2011 10:01 AM, Gordon Sim wrote:
We don't support session resume so session timeout at the AMQP 0-10
level is not used at present. I prefer to keep this entirely separate
rather than mix it in with that. It is certainly possible to have a
session level timeout value in clients and use that for all temporary
queues.


As the perceived behaviour would be the same, why use it, or rather put
the timeout on the session as an extra param.

Not quite sure what you are suggesting here.

The session-attach control in 0-10 doesn't allow for arbitrary implementation specific options if that is what you mean. (In any case I don't see that avoiding an additional variable, nor being more logical given that a session timeout is something already defined by the spec even if we don't implement it).

My concerns is the user
complexity of having timeout on every queue.

I don't think it adds complexity. It is also entirely optional. Repeating the point above, the fact that it is set per queue can in many cases be hidden from the application (e.g. we can have a connection level option controlling timeout for reliable subscriptions with a sensible default that would mean users did not even need to explicitly know about the queue level option).

A further point in favour of a per-queue timeout is that it applies also to cases where potentially multiple sessions consume from a queue and the queue is deleted only when the last consumer is cancelled (see AMQP spec).

Another, perhaps slightly more contrived, is that different queues may benefit from different timeouts. For example a queue which might grow rapidly with less-than-critical messages might be configured with a relatively short timeout e.g. a response queue; a queue with fewer critical responses may merit a longer timeout (e.g. a durable subscription queue).


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[email protected]

Reply via email to