On 10 October 2014 15:02, Gordon Sim <[email protected]> wrote: > On 10/10/2014 10:52 AM, Holger Joukl wrote: > >> Gordon Sim <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
