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 <[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]
