On 10/10/2014 09:34 AM, Holger Joukl wrote:
this is my first post to this list, please bear with my rather lengthy
mail.
I've just started toying around with qpid and have some questions I
couldn't find
answers to in the documentation:
I'm running qpidd using qpid-cpp-server 0.14 and python-qpid 0.14
(as available as rpm for this RHEL 6.3 server). I'm aware this might be
version-related issues so please tell me right away if I need to build
and install a more up-to-date version :-).
Btw are there more recent rpms known to work on RHEL 6?
Here goes:
I'm sending messages with a simple python sender to such an address:
$ i=0
$ let i=$i+1; ./qpid_send.py "mytopic; {assert:always, create:always, node:
{type: topic, durable: True}, link: {reliability: exactly-once}}" "hello:
$i"
...and receive the messages with a simple python receiver using this
address:
$ ./qpid_listen.py "mytopic; {node: {durable: True}, link: {name:sub1_1,
reliability: exactly-once, durable: True}}"
What I want is reliable publish-subscribe, i.e. no message loss is
tolerable:
- ideally a quality-of-service of exactly-once (but I've spotted in the
docs
that this is not supported (yet?) and falls back to at-least-once)
Exactly-once is not supported, at-least-once is. That will prevent
message loss but may result in duplicates.
- messages that originated during receiver downtime must be redelivered
It seems like I have this basically working, but only if my receiving
program
*does not* explicitly close the connection when shut down.
[...]
Re-delivery of messages that were sent during receiver downtime does only
work for me
when *not* calling connection.close() on receiver shutdown. Is this
intended behaviour?
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.
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.
You can also create and bind (and delete) the queue programatically
using QMF (qpid management framework) messages.
Could you point me to relevant parts in the docs?
Next question: If a program wants to subscribe to multiple topics I need
separate
receivers for each of the topics(?).
Yes.
It seems I haven't quite understood the use of names as in "session name"
and "link name" here.
Does the session name have any practical relevance?
Not really, no. It may help to identify particular sessions when using
management tools, but usually its fine to use the auto-generated uuid.
The link names are more important. They control the name of the
subscription queue if relevant, so if you need to be able to handlethe
receiver process crashing then resuming its subscription, it needs to
use a well known link name in order to subscribe back to the right queue.
Is my assumption correct that I *can not* reuse a link name for a 2nd topic
subscription?
E.g. if I do this...
$ ./qpid_listen.py "mytopic; {node: {durable: True}, link: {name:sub1,
reliability: exactly-once, durable: True}}" "mytopic2; {node: {durable:
True}, link: {name:sub1, reliability: exactly-once, durable: True}}"
(note the same link name "sub1" used for both topics)
...and only the sender for "mytopic; {assert:always, create:always, node:
{type: topic, durable: True}, link: {reliability: exactly-once}}"
is active, I'm seeing the messages retrieved alternately be the 2
receivers:
Yes, that is because they are sharing the same subscription queue (which
is taken from the link name).
mytopic; {node: {durable: True}, link: {name:sub1, reliability:
exactly-once, durable: True}} received: Message(durable=True,
content='hallo: 1')
content: 'hallo: 1'
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
mytopic2; {node: {durable: True}, link: {name:sub1, reliability:
exactly-once, durable: True}} received: Message(durable=True,
content='hallo: 2')
content: 'hallo: 2'
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
I guess the link basically constitutes a unique internal input queue for a
receiver
so name reuse will actually have the 2nd receiver dispatch messages from
this queue,
too, although this is "connected" to "mytopic", not "mytopic2".
Hence, I'd need to use distinct link names for the 2 subscriptions.
Is this understanding correct?
Yes, that is exactly correct.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
