You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2014/10/10 16:02:32 UTC
durable subscriptions with AMQP 1.0 (was Re: [qpid-users] Reliable
pub-sub, redelivery of missed messages)
On 10/10/2014 10:52 AM, Holger Joukl wrote:
> Gordon Sim <gs...@redhat.com> schrieb am 10.10.2014 11:25:49:
>
>> Yes, an explicit close is taken as a signal that the subscription is no
>> longer needed and it will indeed delete the subscription queue. Though I
>> can see this might be a little awkward/inconvenient, tere isn't really
>> any other way in the API at present to cancel a subscription.
>
> Is this documented anywhere? It took me quite some time to find out because
> I didn't expect this behaviour at all. Maybe I've looked at all the
> wrong places.
Not really. It's sort of an implicit thing that an explicit close of the
receiver is cancelling the subscription, and an explicit close of the
connection and/or session, will result in closing all associated senders
and receivers.
Really it needs an option on close or even a separate method to indicate
the receiver is merely being suspended.
>> You can instead have a queue bound to the relevant exchange and just
>> have the subscriber receive from that. When you no longer need the
>> subscription you can delete the queue.
>>
>> You can if desired have the queue created automatically when creating a
>> receiver. E.g. using the following address:
>>
>> my-sub; {create:always,
>> link:{x-bindings:[exchange:my-exchange,key:my-key]}}
>>
>> Note though that this does limit you to using AMQP 0-10.
>
> This is not really an option if we went down the AMQP route using QPid
> (or probably RHEL MRG, rather). I take it the internal QPid architecture
> probably pretty much consists of the pre-AMQP-1.0 broker components
> (exchange,
> binding, queue), just like RabbitMQ continues to use AMQP 0.9.1 as its
> internal
> implementation protocol (haven't looked at any qpid code, just deducing
> from docs
> and examples).
> Which seems perfectly fine considering the broader scope of the older
> standard
> versions in this respect, but I would want to rather use the future-proof
> "public API".
The good news there is that there is to be a standard mapping for JMS to
AMQP 1.0, and since JMS supports durable subscriptions, this use case
will be covered in that mapping. Even at present I suspect that the
current qpid 1.0 based JMS client will use a mechanism that has support
outside Qpid. Not sure what that is exactly, but perhaps Rob or Robbie
can comment? How are durable subscriptions created and cancelled over
AMQP 1.0?
The less good news is that at present the qpid.messaging python client
only supports AMQP 0-10 anyway. That is not because of any inherent
difficulty in doing so. It has just been a matter of priorities.
There has been some discussion about APIs on this list in recent months.
As a result of those I have been working on some examples of what using
proton more directly, in conjunction with a 'toolkit' of utilities
around the new event API, might look like[1].
[1]
https://svn.apache.org/repos/asf/qpid/proton/branches/examples/tutorial/helloworld.py
https://svn.apache.org/repos/asf/qpid/proton/branches/examples/tutorial/helloworld_blocking.py
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: durable subscriptions with AMQP 1.0 (was Re: [qpid-users] Reliable pub-sub, redelivery
of missed messages)
Posted by Holger Joukl <Ho...@LBBW.de>.
Gordon Sim schrieb am 10.10.2014 16:02:32:
> The good news there is that there is to be a standard mapping for JMS to
> AMQP 1.0, and since JMS supports durable subscriptions, this use case
> will be covered in that mapping. Even at present I suspect that the
> current qpid 1.0 based JMS client will use a mechanism that has support
> outside Qpid. Not sure what that is exactly, but perhaps Rob or Robbie
> can comment? How are durable subscriptions created and cancelled over
> AMQP 1.0?
>
> The less good news is that at present the qpid.messaging python client
> only supports AMQP 0-10 anyway. That is not because of any inherent
> difficulty in doing so. It has just been a matter of priorities.
Ah, I wasn't aware of this, as of the version info given here:
http://qpid.apache.org/components/messaging-api/index.html
Of course, the qpid version 0.14 I'm experimenting with right now is pre
1-0
anyway.
> There has been some discussion about APIs on this list in recent months.
> As a result of those I have been working on some examples of what using
> proton more directly, in conjunction with a 'toolkit' of utilities
> around the new event API, might look like[1].
>
> [1]
> https://svn.apache.org/repos/asf/qpid/proton/branches/examples/
> tutorial/helloworld.py
> https://svn.apache.org/repos/asf/qpid/proton/branches/examples/
> tutorial/helloworld_blocking.py
Got to have a look at these.
Thanks again,
Holger
Landesbank Baden-Wuerttemberg
Anstalt des oeffentlichen Rechts
Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz
HRA 12704
Amtsgericht Stuttgart
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: durable subscriptions with AMQP 1.0 (was Re: [qpid-users]
Reliable pub-sub, redelivery of missed messages)
Posted by Rob Godfrey <ro...@gmail.com>.
Yep - that's how the current JMS client is working
-- Rob
On 10 October 2014 18:02, Gordon Sim <gs...@redhat.com> wrote:
> On 10/10/2014 04:27 PM, Rob Godfrey wrote:
>
>> So, it is trying to update the remote terminus to change the expiry policy
>> from NEVER to LINK_DETACH and the to close the link (thus destroying it).
>> The seemingly duplicate call is because the first attempt to open the
>> receiver doesn't set a source object and so the broker may just send back
>> the current source rather than modifying it to change the durability. I
>> believe this works with the Qpid Java Broker and SwiftMQ - I'm not sure
>> whether it has been tested with the C++ Broker, ActiveMQ or others....
>>
>
> So on subscribing you create a receiving link with terminus expiry policy
> set to never, and then on cancel you detach the receiver, re-open it with a
> terminus-expiry of link-detach and then close the link?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: durable subscriptions with AMQP 1.0 (was Re: [qpid-users] Reliable
pub-sub, redelivery of missed messages)
Posted by Gordon Sim <gs...@redhat.com>.
On 10/10/2014 04:27 PM, Rob Godfrey wrote:
> So, it is trying to update the remote terminus to change the expiry policy
> from NEVER to LINK_DETACH and the to close the link (thus destroying it).
> The seemingly duplicate call is because the first attempt to open the
> receiver doesn't set a source object and so the broker may just send back
> the current source rather than modifying it to change the durability. I
> believe this works with the Qpid Java Broker and SwiftMQ - I'm not sure
> whether it has been tested with the C++ Broker, ActiveMQ or others....
So on subscribing you create a receiving link with terminus expiry
policy set to never, and then on cancel you detach the receiver, re-open
it with a terminus-expiry of link-detach and then close the link?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: durable subscriptions with AMQP 1.0 (was Re: [qpid-users]
Reliable pub-sub, redelivery of missed messages)
Posted by Rob Godfrey <ro...@gmail.com>.
On 10 October 2014 17:03, Robbie Gemmell <ro...@gmail.com> wrote:
> On 10 October 2014 15:02, Gordon Sim <gs...@redhat.com> wrote:
>
> > On 10/10/2014 10:52 AM, Holger Joukl wrote:
> >
> >> Gordon Sim <gs...@redhat.com> schrieb am 10.10.2014 11:25:49:
> >>
> >> Yes, an explicit close is taken as a signal that the subscription is no
> >>> longer needed and it will indeed delete the subscription queue. Though
> I
> >>> can see this might be a little awkward/inconvenient, tere isn't really
> >>> any other way in the API at present to cancel a subscription.
> >>>
> >>
> >> Is this documented anywhere? It took me quite some time to find out
> >> because
> >> I didn't expect this behaviour at all. Maybe I've looked at all the
> >> wrong places.
> >>
> >
> > Not really. It's sort of an implicit thing that an explicit close of the
> > receiver is cancelling the subscription, and an explicit close of the
> > connection and/or session, will result in closing all associated senders
> > and receivers.
> >
> > Really it needs an option on close or even a separate method to indicate
> > the receiver is merely being suspended.
> >
> > You can instead have a queue bound to the relevant exchange and just
> >>> have the subscriber receive from that. When you no longer need the
> >>> subscription you can delete the queue.
> >>>
> >>> You can if desired have the queue created automatically when creating a
> >>> receiver. E.g. using the following address:
> >>>
> >>> my-sub; {create:always,
> >>> link:{x-bindings:[exchange:my-exchange,key:my-key]}}
> >>>
> >>> Note though that this does limit you to using AMQP 0-10.
> >>>
> >>
> >> This is not really an option if we went down the AMQP route using QPid
> >> (or probably RHEL MRG, rather). I take it the internal QPid architecture
> >> probably pretty much consists of the pre-AMQP-1.0 broker components
> >> (exchange,
> >> binding, queue), just like RabbitMQ continues to use AMQP 0.9.1 as its
> >> internal
> >> implementation protocol (haven't looked at any qpid code, just deducing
> >> from docs
> >> and examples).
> >> Which seems perfectly fine considering the broader scope of the older
> >> standard
> >> versions in this respect, but I would want to rather use the
> future-proof
> >> "public API".
> >>
> >
> > The good news there is that there is to be a standard mapping for JMS to
> > AMQP 1.0, and since JMS supports durable subscriptions, this use case
> will
> > be covered in that mapping. Even at present I suspect that the current
> qpid
> > 1.0 based JMS client will use a mechanism that has support outside Qpid.
> > Not sure what that is exactly, but perhaps Rob or Robbie can comment? How
> > are durable subscriptions created and cancelled over AMQP 1.0?
> >
> > The JMS mapping has yet to cover durable subscriptions. The existing
> client, and the new one Tim and I are working on, currently subscribe using
> the subscription name as the receiver link name and set the source terminus
> durability to unsettled-state/2. After a quick look I dont actually
> understand what the existing client is trying to do (Rob?)
So, it is trying to update the remote terminus to change the expiry policy
from NEVER to LINK_DETACH and the to close the link (thus destroying it).
The seemingly duplicate call is because the first attempt to open the
receiver doesn't set a source object and so the broker may just send back
the current source rather than modifying it to change the durability. I
believe this works with the Qpid Java Broker and SwiftMQ - I'm not sure
whether it has been tested with the C++ Broker, ActiveMQ or others....
-- Rob
> for the
> unsubscribe call, but it ends with a //TODO. The new client as yet does
> nothing for unsubscribe.
>
>
>
> > The less good news is that at present the qpid.messaging python client
> > only supports AMQP 0-10 anyway. That is not because of any inherent
> > difficulty in doing so. It has just been a matter of priorities.
> >
> > There has been some discussion about APIs on this list in recent months.
> > As a result of those I have been working on some examples of what using
> > proton more directly, in conjunction with a 'toolkit' of utilities around
> > the new event API, might look like[1].
> >
> > [1] https://svn.apache.org/repos/asf/qpid/proton/branches/
> > examples/tutorial/helloworld.py
> > https://svn.apache.org/repos/asf/qpid/proton/branches/
> > examples/tutorial/helloworld_blocking.py
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
Re: durable subscriptions with AMQP 1.0 (was Re: [qpid-users]
Reliable pub-sub, redelivery of missed messages)
Posted by Robbie Gemmell <ro...@gmail.com>.
On 10 October 2014 15:02, Gordon Sim <gs...@redhat.com> wrote:
> On 10/10/2014 10:52 AM, Holger Joukl wrote:
>
>> Gordon Sim <gs...@redhat.com> schrieb am 10.10.2014 11:25:49:
>>
>> Yes, an explicit close is taken as a signal that the subscription is no
>>> longer needed and it will indeed delete the subscription queue. Though I
>>> can see this might be a little awkward/inconvenient, tere isn't really
>>> any other way in the API at present to cancel a subscription.
>>>
>>
>> Is this documented anywhere? It took me quite some time to find out
>> because
>> I didn't expect this behaviour at all. Maybe I've looked at all the
>> wrong places.
>>
>
> Not really. It's sort of an implicit thing that an explicit close of the
> receiver is cancelling the subscription, and an explicit close of the
> connection and/or session, will result in closing all associated senders
> and receivers.
>
> Really it needs an option on close or even a separate method to indicate
> the receiver is merely being suspended.
>
> You can instead have a queue bound to the relevant exchange and just
>>> have the subscriber receive from that. When you no longer need the
>>> subscription you can delete the queue.
>>>
>>> You can if desired have the queue created automatically when creating a
>>> receiver. E.g. using the following address:
>>>
>>> my-sub; {create:always,
>>> link:{x-bindings:[exchange:my-exchange,key:my-key]}}
>>>
>>> Note though that this does limit you to using AMQP 0-10.
>>>
>>
>> This is not really an option if we went down the AMQP route using QPid
>> (or probably RHEL MRG, rather). I take it the internal QPid architecture
>> probably pretty much consists of the pre-AMQP-1.0 broker components
>> (exchange,
>> binding, queue), just like RabbitMQ continues to use AMQP 0.9.1 as its
>> internal
>> implementation protocol (haven't looked at any qpid code, just deducing
>> from docs
>> and examples).
>> Which seems perfectly fine considering the broader scope of the older
>> standard
>> versions in this respect, but I would want to rather use the future-proof
>> "public API".
>>
>
> The good news there is that there is to be a standard mapping for JMS to
> AMQP 1.0, and since JMS supports durable subscriptions, this use case will
> be covered in that mapping. Even at present I suspect that the current qpid
> 1.0 based JMS client will use a mechanism that has support outside Qpid.
> Not sure what that is exactly, but perhaps Rob or Robbie can comment? How
> are durable subscriptions created and cancelled over AMQP 1.0?
>
> The JMS mapping has yet to cover durable subscriptions. The existing
client, and the new one Tim and I are working on, currently subscribe using
the subscription name as the receiver link name and set the source terminus
durability to unsettled-state/2. After a quick look I dont actually
understand what the existing client is trying to do (Rob?) for the
unsubscribe call, but it ends with a //TODO. The new client as yet does
nothing for unsubscribe.
> The less good news is that at present the qpid.messaging python client
> only supports AMQP 0-10 anyway. That is not because of any inherent
> difficulty in doing so. It has just been a matter of priorities.
>
> There has been some discussion about APIs on this list in recent months.
> As a result of those I have been working on some examples of what using
> proton more directly, in conjunction with a 'toolkit' of utilities around
> the new event API, might look like[1].
>
> [1] https://svn.apache.org/repos/asf/qpid/proton/branches/
> examples/tutorial/helloworld.py
> https://svn.apache.org/repos/asf/qpid/proton/branches/
> examples/tutorial/helloworld_blocking.py
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>