No, it is used client side in the 0-8/0-9/0-9-1 session/consumer code to influence its rejection behaviour. If you follow the use of the constant I'm sure you will run into it fairly quickly.
I'm not sure how used (if at all) the other two options you singled out are, but this one is. Robbie On 15 May 2012 14:24, Rajith Attapattu <[email protected]> wrote: > Alex, > > Thanks for the explanation. > I assume this is passed as a queue-declare argument ? > > Regards, > > Rajith > > > On Tue, May 15, 2012 at 4:30 AM, Oleksandr Rudyy <[email protected]> wrote: > >> Hi Rajith, >> >> Option reject_behaviour was introduced as part of work on implementing >> DLQ functionality in java broker. This is only 0-9-1 client setting >> and it is not needed for 0-10 client. >> By default, redelivered messages are not moved into DLQ after >> exceeding Maximum redelivery attempts (for backward compatibility). In >> order to have redelivered messages to be moved into DLQ after reaching >> Maximum redelivery number the client should set >> reject_behaviour=server either as a connection option or a queue >> Binding URL option. >> >> Kind Regards, >> Alex >> >> >> >> On 14 May 2012 22:36, Rajith Attapattu <[email protected]> wrote: >> > Hi All, >> > >> > I'm trying to compile an exhaustive list of all the valid options for >> > binding URL. >> > Some of the options make sense while others a lot is left to be desired. >> > I'd really appreciate some help in agreeing to a proper list and also >> > updating the wiki for accuracy. >> > >> > The wiki page here >> > https://cwiki.apache.org/qpid/bindingurlformat.htmldescribes the >> > following options. >> > >> > exclusive boolean Is this an exclusive connection >> > autodelete boolean Should this queue be deleted on client >> > disconnection >> > durable boolean Create a durable queue >> > clientid string Use the following client id >> > subscription boolean Create a subscription to this destination >> > routingkey string Use this value as the routing key >> > >> > While the code has the following options, >> > >> > public static final String OPTION_EXCLUSIVE = "exclusive"; >> > public static final String OPTION_AUTODELETE = "autodelete"; >> > public static final String OPTION_DURABLE = "durable"; >> > public static final String OPTION_BROWSE = "browse"; >> > public static final String OPTION_CLIENTID = "clientid"; >> > public static final String OPTION_SUBSCRIPTION = "subscription"; >> > public static final String OPTION_ROUTING_KEY = "routingkey"; >> > public static final String OPTION_BINDING_KEY = "bindingkey"; >> > public static final String OPTION_REJECT_BEHAVIOUR = "rejectbehaviour"; >> > >> > (*) Multiple Binding keys can be specified. >> > >> > While most of the options are quite straight forward I'm trying to figure >> > out the intended behaviour for a few. >> > >> > 1. Subscription >> > What's the intended usage for "subscription" ? >> > All though the wiki lists it as a boolean it has been used in a >> rather >> > bizarre way in the BindingURLParser.java >> > (All though I was the author of BindingURLParser I simply used the >> > same that was there in the old code). >> > >> > Could we remove this option? >> > >> > 2. Client ID >> > We don't use the queue-name worked out here in anyway when we create >> > the durable subscription name. >> > Could we remove this option ? >> > >> > 3. OPTION_REJECT_BEHAVIOUR >> > Could somebody please explain the intended behaviour for this option >> > so I could correctly pass it when creating the address structure out of a >> > BURL. >> > >> > Regards, >> > >> > Rajith >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
