[rabbitmq-discuss] Queue.declare arguments

[Pieter de Zwart]

Hey everyone,

I am trying to implement support for passing arguments to queue.declare in the PHP extension for AMQP. Based on the docs, arguments are up to the server to implement, but are based on an amqp_table_t structure. Based on previous email threads and some basic research, the full list of supported keys for the table seem to be: x-expires, x-message-ttl, x-ha-policy and x-ha-policy-params. Is this still the complete list? It seems like I should just give people the ability to set any key they want.

The definition of an amqp_table_entry is a key (amqp_bytes) and value (amqp_field_value_t). The latter has a definition of:

typedef struct amqp_field_value_t_ { char kind; union { amqp_boolean_t boolean; int8_t i8; uint8_t u8; int16_t i16; uint16_t u16; int32_t i32; uint32_t u32; int64_t i64; uint64_t u64; float f32; double f64; amqp_decimal_t decimal; amqp_bytes_t bytes; amqp_table_t table; amqp_array_t array; } value; } amqp_field_value_t;

Im assuming therefore that I can shove any kind/value combo for any key, and let the rabbitmq-c client/broker figure out the details. Is that correct?

Thank you for your help.

Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111011/066f830b/attachment.htm>

[Simon MacMullen]

Post by Pieter de Zwart
I am trying to implement support for passing arguments to queue.declare
in the PHP extension for AMQP. Based on the docs, arguments are up to
the server to implement, but are based on an amqp_table_t structure.
Based on previous email threads and some basic research, the full list
of supported keys for the table seem to be: x-expires, x-message-ttl,
x-ha-policyand x-ha-policy-params. Is this still the complete list?

It is today. And I don't think any more arguments are on the drawing
board right now, but we may well introduce more in the future.

It's worth pointing out that arguments matter for more than just queues,
they can be used with exchanges (we implement one extension argument,
"alternate-exchange") and also as part of routing with the headers
exchange type (for which you need to be able to set arbitrary arguments
on bindings).

Post by Pieter de Zwart
It
seems like I should just give people the ability to set any key they want.

That is the right thing to do, and it's what we do in our clients.

Post by Pieter de Zwart
The definition of an amqp_table_entry is a key (amqp_bytes) and value
typedef struct amqp_field_value_t_ { char kind; union { amqp_boolean_t
boolean; int8_t i8; uint8_t u8; int16_t i16; uint16_t u16; int32_t i32;
uint32_t u32; int64_t i64; uint64_t u64; float f32; double f64;
amqp_decimal_t decimal; amqp_bytes_t bytes; amqp_table_t table;
amqp_array_t array; } value; } amqp_field_value_t;
Im assuming therefore that I can shove any kind/value combo for any key,
and let the rabbitmq-c client/broker figure out the details. Is that
correct?

Not really - the values in AMQP are typed. These types will be pushed
through unchanged by the C client, but the broker will want you to set
sensible types. We try to be reasonably flexible, but if you're setting
the x-expires argument for example then we'll expect one of the integer
types; we won't just parse a string.

Cheers, Simon

[David Wragg]

Hi Pieter,

Post by Pieter de Zwart
I am trying to implement support for passing arguments to
queue.declare in the PHP extension for AMQP. Based on the docs,
arguments are up to the server to implement, but are based on an
amqp_table_t structure. Based on previous email threads and some basic
x-expires, x-message-ttl, x-ha-policy and x-ha-policy-params. Is this
still the complete list? It seems like I should just give people the
ability to set any key they want.

Yes. Even if that list is complete today, it might not be complete in
the future.

Post by Pieter de Zwart
The definition of an amqp_table_entry is a key (amqp_bytes) and value
typedef struct amqp_field_value_t_ { char kind; union { amqp_boolean_t
boolean; int8_t i8; uint8_t u8; int16_t i16; uint16_t u16; int32_t
i32; uint32_t u32; int64_t i64; uint64_t u64; float f32; double f64;
amqp_decimal_t decimal; amqp_bytes_t bytes; amqp_table_t table;
amqp_array_t array; } value; } amqp_field_value_t;
Im assuming therefore that I can shove any kind/value combo for any
key, and let the rabbitmq-c client/broker figure out the details. Is
that correct?

Yes. AMQP tables are just name -> typed value dictionaries. In certain
contexts (such as queue.declare arguments) the broker defines a
particular meaning for them. In others (e.g. message headers) the
interpretation is up to applications. (Actually, this is not entirely
true for message headers any more - there are RabbitMQ protocol
extensions that involve certain message headers influencing broker
behaviour).

See
<https://github.com/rabbitmq/rabbitmq-c/blob/master/tests/test_tables.c>
for rabbitmq-c code that constructs tables.