You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2012/05/14 23:36:19 UTC
Binding URL Options
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
Re: Binding URL Options
Posted by Rajith Attapattu <ra...@gmail.com>.
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 <or...@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 <ra...@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 <or...@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 <ra...@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-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Binding URL Options
Posted by Oleksandr Rudyy <or...@gmail.com>.
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 <ra...@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 <or...@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 <ra...@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-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Binding URL Options
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <ra...@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 <or...@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 <ra...@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-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Binding URL Options
Posted by Rajith Attapattu <ra...@gmail.com>.
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 <or...@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 <ra...@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Binding URL Options
Posted by Oleksandr Rudyy <or...@gmail.com>.
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 <ra...@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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org