Gordon,
thanks very much for your quick and detailed answer!
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.
> 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".
Thanks again,
Holger
Landesbank Baden-Wuerttemberg
Anstalt des oeffentlichen Rechts
Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz
HRA 12704
Amtsgericht Stuttgart
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
