On 10 October 2014 17:03, Robbie Gemmell <[email protected]> wrote:
> 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?) 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
