Why three styles for declaring queue parameters?

[Jonathan Robie <jo...@redhat.com>]

I don't understand why we have two different styles for declaring queue 
parameters.

Some have explicit parameters that are used in session.queueDeclare:

session.queueDeclare(arg::queue=myQueue,
        arg::exclusive=true,
        arg::autoDelete=true);

We have defined arg:queue, arg::durable, arg::autoDelete, arg:exclusive, 
and arg:alternateExchange.

How are these different from QueueSizePolicy or QueueOrderingPolicy, 
which take a second approach (specifying values for a property)?

QueueOptions qo;
qo.setOrdering(LVQ);
session.queueDeclare(arg::queue=queue, arg::arguments=qo);
And how are these different from persisting the last node or queue 
events, which take a third approach (specifying properties for the queue)?
QueueOptions qo;
qo.clearPersistLastNode();
session.queueDeclare(arg::queue=queue, arg::durable=true, 
arg::arguments=qo);

QueueOptions options;
options.enableQueueEvents(false);
session.queueDeclare(arg::queue="my-queue", arg::arguments=options);


Can we pick just one way of doing this?

Jonathan

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

Re: Why three styles for declaring queue parameters?

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

On 09/10/2009 08:24 PM, Jonathan Robie wrote:
> I don't understand why we have two different styles for declaring queue
> parameters.
>
> Some have explicit parameters that are used in session.queueDeclare:
>
> session.queueDeclare(arg::queue=myQueue,
> arg::exclusive=true,
> arg::autoDelete=true);
>
> We have defined arg:queue, arg::durable, arg::autoDelete, arg:exclusive,
> and arg:alternateExchange.
>
> How are these different from QueueSizePolicy or QueueOrderingPolicy,
> which take a second approach (specifying values for a property)?

The arguments to the queueDeclare() are generated from the AMQP 
specification. In addition to those you mention above there is an 
'arguments' field, whose syntax and semantics depend on the server 
implementation.

We use those arguments to communicate particular properties to the 
queues (such as size limitations, or extended semantics). They are 
passed in as an amqp 0-10 'map', which in the c++ client is currently 
represented by the FieldTable type.

QueueOptions is merely a helper class that extends FieldTable to add in 
some explicit methods making it more convenient to set common options.

> QueueOptions qo;
> qo.setOrdering(LVQ);
> session.queueDeclare(arg::queue=queue, arg::arguments=qo);
> And how are these different from persisting the last node or queue
> events, which take a third approach (specifying properties for the queue)?

They aren't, however the signatures of these helper methods vary 
depending on the interpretation of the property value. For the ordering 
option, an enumeration is defined as there are three different 
possibilities. The 'persist-last-node' option is just a flag and it 
offers setPersistLastNode()/clearPersistLastNode().

> QueueOptions qo;
> qo.clearPersistLastNode();
> session.queueDeclare(arg::queue=queue, arg::durable=true,
> arg::arguments=qo);

I suspect the above is not what you want. The clearPersisteLastNode() 
method removes an option, but the option is not set by default so you 
are simply passing an empty map here. I suspect you meant to use 
setPersistLastNode()?

>
> QueueOptions options;
> options.enableQueueEvents(false);
> session.queueDeclare(arg::queue="my-queue", arg::arguments=options);

You could argue that an enumeration would be more consistent here. We 
can add that in addition to the above if you like.

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