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