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

Compare with Current View Page History

Version 1 Next »

The proposal is organized as follows.

1. Design concepts/notes
2. Configuration format with examples
3. Complete list of options available
4. Code patch (attached to JIRA)

Design concepts/notes

  • I have moved away from the previous URL format as it,
    • Does not clearly identify a resource, hence against the concept of a URL
    • It is impossible to fit all information in to a URL
  • The new format is integrated alongside the old system with absolutely no change to existing way of doing things.
    A mix and match of both the old and new system could be used (if really needed).
  • The new format takes ideas from the AMQP 1.0 spec.
    But it is not intended to support AMQP 1.0 when it comes out. If it ends up being a pre-cursor for supporting AMQP 1.0 it would just be a bonus.
  • The new format clearly identifies the dual role of a javax.jms.Destination.
    That being the producer and consumer's view of a destination.
  • The new format allows a way to support,
    • 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
      • msg credits, byte credits
      • sync-publish, sync-ack
      • whether a queue should be created/bound by producer side
    • Bind a queue to multiple exchange/binding key pairs.
  • Define queues, links and then compose them to create destinations.
  • Provides sensible defaults . At least I tried to (smile).

Configuration format with examples

The new format consists of definitions for queues, publisher/consumer links and destinations in key/value pairs.

 
xqueue.<id> = name='value1'[;key2='value2';key3='value3'......]
pub.link.<id> = key1='value1';key2='value2';key3='value3'......
sub.link.<id> = key1='value1';key2='value2';key3='value3'......

xdestination.<jndiName> = queue='<id>'[;pub.link='<id>';sub.link='<id>']

Using queue, pub/sub links def's you can compose destinations.

Examples

In the simplest form

 
xqueue.myQueue = name='myQueue'
xdestination.myQueue = queue=myQueue

This is equivalent to the old queue = myQueue format.

Using qpid specific options and per destination switches

 
xqueue.tradeQueue1 = name='trade-queue1';durable='true'
xqueue.tradeQueue2 = name='trade-queue2';qpid.max_size='5000';qpid.policy_type='ring'

pub.link.trade1 = filter='amq.direct/tradeQueue1';sync-publish='all'
pub.link.trade2 = filter='amq.direct/tradeQueue2';create-queue='true'

sub.link.mylink = msg-credits='1000';byte-credits='1000';sync-ack='true'

xdestination.myLocalTrades = queue='tradeQueue1';pub.link='trade1';sub.link='myLink'

xdestination.myDailyTrades = queue='tradeQueue2';pub.link='trade2';sub.link='myLink'

Binding a queue to multiple exchange/routing key pairs

 
Using the above queue definition.

sub.link.multiLink = msg-credits='1000';bindings='{amq.topic/stocks.*};{amq.match//x-match='any',sym='RHT'}'

xdestination.myDailyTrades = queue='tradeQueue2';sub.link='multiLink'

Complete list of options

  • xqueue
    • 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)
  • sub.link
    • filter
    • filter-type
    • msg-credits
    • byte-credits
    • sync-ack
    • bindings - format as follows 
       {exchange-name/bindingkey[/key=value,key=value,...};{....}..]
  • pub.link
    • filter
    • filterType
    • sync-publish {persistent|all}
    • create-queue (producer side will declare/bind the queue)
  • No labels