Guys, thx for the explanation. I will have a look at the code to see how best to carry this option in the address structure. It appears that this can be put under x-subscriber map.
When I post the code in this area, I will make sure to ping you both to ensure I got it right. Thanks again Rajith On Wed, May 16, 2012 at 4:25 AM, Oleksandr Rudyy <oru...@gmail.com> wrote: > Hi Rajith, > > I am sorry for a delayed reply. > Option "reject_behaviour" is a client setting only and it is not > passed into queue declare arguments. With reject_behaviour=server the > 0-9-x client sends BasicReject commands for unacknowledged messages on > recover to reject these messages either for the entire connection > globally or only for the queues with this behaviour. With > reject_behaviour=normal 0-9-x client sends BasicRecoverSyncOk command > only on session recover. > > Kind Regards, > Alex > > On 15 May 2012 14:24, Rajith Attapattu <rajit...@gmail.com> 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 <oru...@gmail.com> > 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 <rajit...@gmail.com> 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: dev-unsubscr...@qpid.apache.org > >> For additional commands, e-mail: dev-h...@qpid.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > >
