It looks like Carl already has documented some of the options here. http://cwiki.apache.org/confluence/display/qpid/Cheat+Sheet+for+configuring+Queue+Options
Rajith On Fri, Oct 3, 2008 at 2:04 PM, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > On Fri, Oct 3, 2008 at 4:18 AM, Martin Ritchie <[EMAIL PROTECTED]>wrote: > >> 2008/10/2 Rajith Attapattu <[EMAIL PROTECTED]>: >> > On Thu, Oct 2, 2008 at 6:14 AM, Martin Ritchie <[EMAIL PROTECTED]> >> wrote: >> > >> >> 2008/10/1 Rajith Attapattu <[EMAIL PROTECTED]>: >> >> > Hi All, >> >> > >> >> > Currently we cannot specify arguments for Queue binding and declare, >> >> using >> >> > the binding URL in the JNDI props file. >> >> > >> >> > This prohibits the JMS client to leverage some of the options offered >> by >> >> the >> >> > C++ broker. >> >> > a) Use the XML exchange as you need to specify the xpath expression >> as a >> >> > binding argument. >> >> > b) Use queue configuration options ( Ex qpid.max_size, >> qpid.max_count, >> >> > qpid.policy_type ...etc) >> >> > >> >> > Another limitation is that a queue could only be bound to a single >> >> exchange >> >> > (all though now you could specify multiple binding keys). >> >> > >> >> > It would be nice if we found a way to express the above using our >> JNDI >> >> prop >> >> > file. >> >> > One idea is to use the following format. >> >> > bind.args.<prop_name>=<prop_value> and >> dec.args.<prop_name>=<prop_value> >> >> in >> >> > the binding URL. >> >> > This however doesn't solve the problem of binding to multiple >> exchanges. >> >> > >> >> > Another idea floated by Martin was to separate the queue definition >> from >> >> its >> >> > bindings. >> >> > The obvious advantage of this approach is that you could bind your >> queue >> >> to >> >> > multiple exchange/bindingkey pairs. >> >> > Ex. >> >> destination.<jndiname>=myQueue?durable=true&args.qpid.max_size=100000 >> >> > >> >> > >> >> >> binding.<jndiname>=myExchange/myQueue?bindingkey='abc'&args.prop1=prop1value&args.prop2=prop2value >> >> > binding.<jndiname>=amq.direct/myQueue?bindingKey='xyz' >> >> > >> >> > I am sure there are other ideas as well. >> >> > Please help by sharing your ideas on a new propsal or how to refine >> the >> >> > existing mechanism. >> >> > (Eitherway we need to ensure backwards compatibility.) >> >> > >> >> > Regards, >> >> > >> >> > Rajith Attapattu >> >> > Red Hat >> >> > http://rajith.2rlabs.com/ >> >> >> >> Just to refine Rajith's example slightly I think in the binding entry >> >> simply having a list of properties makes for easy parsing and makes >> >> future expansion/change easier as there is no initial string to be >> >> worry about. Do we have a wiki page that details what the args.prop1 >> >> args.prop2 might be? I know this is a 0-10 related addition to the >> >> URLs but I can't remember or locate that documentation just now: >> > >> > >> > I am not aware of such a page, but I believe the intention is to >> document >> > these properties. >> > Jonathan may have already done something on this front. >> >> If Jonathan has then it would be great if he would contribute it to >> the project, I do find it frustrating to hear that there has been >> documentation effort performed but not part of this project. :( >> > > I meant documentation for Qpid project. > I am not aware of any other documentation that has these properties. (I > stand to be corrected though). > > >> >> >> >> >> >> destination.myDestination=myQueue?durable=true&args.qpid.max_size=100000 >> >> >> >> >> binding.myDestination=exchange=myExchange&bindingkey='abc'&args.prop1=prop1value&args.prop2=prop2value >> >> binding.myDestination=exchange=amq.direct&bindingKey='xyz' >> >> >> >> Note that the <jndiname> is the same in all three lines. This would >> >> allow the client library to automatically perform the binding lookup >> >> in JNDI and then perform the AMQP methods, I don't recall what >> >> Property files do if you have multiple items with the same key. >> >> However if it doesn't give us all the values then the easy solution is >> >> to number them, as the XML Configuration would: >> >> >> >> binding.myDestination.1=... >> >> binding.myDestination.2=... >> >> >> >> While if we might allow access through our qpid.jms extensions to >> >> manually bind a destination with a listed JNDI binding I would not >> >> start by offering this functionality. >> > >> > >> > IMHO the first and foremost option should be to expose as much >> functionality >> > through configuration while using 100% pure JMS interfaces. >> > My experiance with users is that they are not too happy about using >> vendor >> > extentions. >> >> That is fine, means less work adding an extra method to the api to >> support but it does mean less flexibility from a clients point of >> view. Then again if we don't have a use case from a client to work >> with it is a little difficult to formulate an solution to their >> problem. >> >> >> >> >> >> >> Thoughts >> >> >> >> Martin >> >> >> >> -- >> >> Martin Ritchie >> >> >> > >> > >> > >> > -- >> > Regards, >> > >> > Rajith Attapattu >> > Red Hat >> > http://rajith.2rlabs.com/ >> > >> >> >> >> -- >> Martin Ritchie >> > > > > -- > Regards, > > Rajith Attapattu > Red Hat > http://rajith.2rlabs.com/ > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/
