You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Holger Joukl <Ho...@LBBW.de> on 2014/10/10 10:34:26 UTC
[qpid-users] Reliable pub-sub, redelivery of missed messages
Hi,
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)
- 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. This is the
source code
of the Python receiver:
#########################################################
#!/usr/bin/env python2.7
# Import the modules we need
import sys
import getpass
# abuse system-python installed package
sys.path.append('/usr/lib/python2.6/site-packages')
from qpid.messaging import *
def main():
import argparse
parser = argparse.ArgumentParser()
parser.add_argument(
'address', nargs='+', help='AMQP address(es)')
parser.add_argument(
'--broker', default='localhost:5672',
help='broker connection address (default: %(default)s)')
parser.add_argument(
'--session', default=getpass.getuser(),
help='session id (default: %(default)s)')
args = parser.parse_args()
listen(args.broker, args.session, args.address)
def listen(broker, session_name, address):
connection = Connection(broker)
try:
connection.open()
# Define the session
session = connection.session(name=session_name)
# Define listener(s)
receivers = []
for addr in address:
receiver = session.receiver(addr)
# needed to allow for prefetch which is in turn necessary for
# multiple sources and the next_receiver() stuff
receiver.capacity = 10
receivers.append(receiver)
startline = ">" * 79
endline = "<" * 79
while True:
receiver = session.next_receiver()
msg = receiver.fetch()
# Output the message
print startline
print "%s received: %s" % (receiver.source, msg)
print " content: '%s'" % msg.content
print endline
session.acknowledge(msg)
except MessagingError, err:
print 'Messaging error:', err
raise
finally:
# Closing the connection seems to cancel interest in the topic?! I
do
# not get redelivery of messages missed due to receiver downtime if
# closing on shutdown...
#connection.close()
pass
if __name__ == '__main__':
main()
#########################################################
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?
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(?).
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?
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:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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?
Thanks for any hints,
best regards
Holger
(Attaching for reference: The Python sender source code:
#########################################################
#!/usr/bin/env python2.7
# Import the modules we need
import sys
# abuse system-python installed package
sys.path.append('/usr/lib/python2.6/site-packages')
from qpid.messaging import *
def main():
import argparse
parser = argparse.ArgumentParser()
parser.add_argument(
'--broker', default='localhost:5672',
help='broker connection address (default: %(default)s)')
parser.add_argument(
'address', help='AMQP address')
parser.add_argument(
'data', help='message text data')
args = parser.parse_args()
send(args.broker, args.address, args.data)
def send(broker, address, data):
connection = Connection(broker)
try:
connection.open()
# Define the session
session = connection.session()
# Define a sender
sender = session.sender(address)
# Send a simple "Hello world!" message to the queue
msg = Message(data, durable=True)
sender.send(msg)
# Output the message
print "Sent '%s'" % msg.content
except MessagingError, err:
print 'Messaging error:', err
raise
finally:
connection.close()
if __name__ == '__main__':
main()
#########################################################
)
Landesbank Baden-Wuerttemberg
Anstalt des oeffentlichen Rechts
Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz
HRA 12704
Amtsgericht Stuttgart
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: durable subscriptions with AMQP 1.0 (was Re: [qpid-users] Reliable pub-sub, redelivery
of missed messages)
Posted by Holger Joukl <Ho...@LBBW.de>.
Gordon Sim schrieb am 10.10.2014 16:02:32:
> 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.
Ah, I wasn't aware of this, as of the version info given here:
http://qpid.apache.org/components/messaging-api/index.html
Of course, the qpid version 0.14 I'm experimenting with right now is pre
1-0
anyway.
> 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
Got to have a look at these.
Thanks again,
Holger
Landesbank Baden-Wuerttemberg
Anstalt des oeffentlichen Rechts
Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz
HRA 12704
Amtsgericht Stuttgart
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: durable subscriptions with AMQP 1.0 (was Re: [qpid-users]
Reliable pub-sub, redelivery of missed messages)
Posted by Rob Godfrey <ro...@gmail.com>.
Yep - that's how the current JMS client is working
-- Rob
On 10 October 2014 18:02, Gordon Sim <gs...@redhat.com> wrote:
> On 10/10/2014 04:27 PM, Rob Godfrey wrote:
>
>> 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....
>>
>
> So on subscribing you create a receiving link with terminus expiry policy
> set to never, and then on cancel you detach the receiver, re-open it with a
> terminus-expiry of link-detach and then close the link?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: durable subscriptions with AMQP 1.0 (was Re: [qpid-users] Reliable
pub-sub, redelivery of missed messages)
Posted by Gordon Sim <gs...@redhat.com>.
On 10/10/2014 04:27 PM, Rob Godfrey wrote:
> 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....
So on subscribing you create a receiving link with terminus expiry
policy set to never, and then on cancel you detach the receiver, re-open
it with a terminus-expiry of link-detach and then close the link?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: durable subscriptions with AMQP 1.0 (was Re: [qpid-users]
Reliable pub-sub, redelivery of missed messages)
Posted by Rob Godfrey <ro...@gmail.com>.
On 10 October 2014 17:03, Robbie Gemmell <ro...@gmail.com> wrote:
> On 10 October 2014 15:02, Gordon Sim <gs...@redhat.com> wrote:
>
> > On 10/10/2014 10:52 AM, Holger Joukl wrote:
> >
> >> Gordon Sim <gs...@redhat.com> 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: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
Re: durable subscriptions with AMQP 1.0 (was Re: [qpid-users]
Reliable pub-sub, redelivery of missed messages)
Posted by Robbie Gemmell <ro...@gmail.com>.
On 10 October 2014 15:02, Gordon Sim <gs...@redhat.com> wrote:
> On 10/10/2014 10:52 AM, Holger Joukl wrote:
>
>> Gordon Sim <gs...@redhat.com> 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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
durable subscriptions with AMQP 1.0 (was Re: [qpid-users] Reliable
pub-sub, redelivery of missed messages)
Posted by Gordon Sim <gs...@redhat.com>.
On 10/10/2014 10:52 AM, Holger Joukl wrote:
> Gordon Sim <gs...@redhat.com> 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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Re: [qpid-users] Reliable pub-sub, redelivery of missed messages
Posted by Holger Joukl <Ho...@LBBW.de>.
Gordon,
thanks very much for your quick and detailed answer!
Gordon Sim <gs...@redhat.com> 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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [qpid-users] Reliable pub-sub, redelivery of missed messages
Posted by Gordon Sim <gs...@redhat.com>.
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org