You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

The proposal is organized as follows.

This proposal is written with input from Rafael and Rob and is intend to support AMQP 1.0 and AMQP 0-8/9/10 as well.

1. Use cases
2. Configuration format with examples
3. Complete list of options available
4. Code patch (attached to JIRA)

1.0 Use cases

The following were requested by Qpid users via JIRA's and user list.

  • Arbitrary exchange types (Ex XML exchange).
  • Any kind of queue declare options (Ex. qpid.max-size, alt-exchange)
  • Any kind of queue binding options
  • Ability to support destination specific parameters like
    o msg credits, byte credits
    o sync-publish, sync-ack
    o whether a queue should be created/bound by producer side

2.0 Configuration format with examples

 
queuex.<name> = {key='value', ...}
destinationx.<name> = <address>                                       # destination without options
destinationx.<name> = <address>; {a='b', c={x='y', z='w', ...}, ...}  # destination with options
  • In a production environment the queues will most likely be pre-configured using an admin tool. However if you need to create queues dynamically the queuex definition allows you to configure your queues in the jndi.properties file it self. It's just a simple key-value pair.
  • The address will encode the following (scheme, node-name, node-type*, subject*) with * denoting optional elements.
  • The exact format is not decided yet. Rafael is planning to use a similar struct for the python client. It would be great if all clients use a similar struct and encoding scheme to represent an address scheme
  • The use of curly braces in the option key-value pairs in the destination is used to facilitate nesting.

'For the purpose of the examples we will assume the following ecoding for the address struct'.

 
<node-type>::<node-name>/<subject>

2.1 Examples

 
<node-name>
<node-type>::<node-name>
<node-type>::<node-name>/<subject>
 
exchange::amq.topic/foo.bar
my-node
my-topic/my-subject.
my-queue/my-subject
my-exchange/my-Subject

2.2 Rules for interpreting the format

  • For 0-10/9/8, node names without a specified type will be resolved to either a queue or an exchange by querying the broker.
  • Subscribing to an exchange will result in a private queue being automatically created and bound (the subject if provided will be used as the binding key).
  • Publishing to an exchange will result in the subject being used as the routing key. Publishing to a queue will result in the default exchange being used to route directly to the queue (note that this will result in the routing key being set to the queue name).
  • In both cases the subject will be set as a message property.

Complete list of options

The options here are not a static list. The format is extensible and new options could be introduced any time in the future.

  • queuex
    • name : name of the queue
    • durable
    • exclusive
    • auto-delete
    • alt-exchange
    • no-local (??)
    • qpid.max_count
    • qpid.max_size
    • qpid.policy_type { reject | flow_to_disk | ring | ring_strict }
    • qpid.last_value_queue {1}
    • qpid.last_value_queue_no_browse {1}
    • qpid.LVQ_key
    • qpid.persist_last_node {1}
    • qpid.queue_event_generation { 0,1,2 } (0 to disable,1 to replicate, only enqueue events)
  • destinationx.
    • filter
    • filter-type
    • msg-credits
    • byte-credits
    • sync-ack
    • sync-publish {persistent|all}
    • bindings - format as follows - a Qpid specific extension for binding a queue to multiple exchange/binding key pairs 
       { bind={exchange-name=<name>, binding-key=<key>, [args={a='b',c='d',...}]} [, bind={}] }
  • No labels