Thanks for the help.
A couple of things... being able to configure lifetime policies on the
broker based on the name of the node is a wonderful idea and I look forward
to that in qpid 0.26. Problem is that I need to have the solution work on
RHEL6 (which ships with qpid 0.14) if possible.
I took some python code from Apache Dispatch Router and modified it to work
with the qpid broker directly without using the dispatch router. Here's
what I have:
---- test.p ----
from proton import Messenger, Message
def main():
host = "127.0.0.1:5673"
messenger = Messenger()
messenger.start()
reply_subscription = messenger.subscribe("amqp://%s/#" % host)
reply_address = reply_subscription.address
print "Reply address: %s" % reply_address
request = Message()
request.address = reply_address
request.reply_to = reply_address
request.body = "proton rocks"
messenger.put(request)
messenger.send()
messenger.recv()
response = Message()
messenger.get(response)
print "Response: %r" % response.body
messenger.stop()
main()
----
This is just using proton, which is great, but the problem is that the
dynamic queues have a permanent lifetime policy as demonstrated here:
Window 1: bash$ qpidd --log-enable trace+ --auth no --port 5673 --interface
127.0.0.1
Window 2: bash$ python test.py
Reply address: amqp://
127.0.0.1:5673/9795cd4c-4d24-42f1-b369-dca989345467_receiver-xxx
Response: 'proton rocks'
bash$ qpid-config -a 127.0.0.1:5673 queues
Queue Name Attributes
======================================================================
9795cd4c-4d24-42f1-b369-dca989345467_receiver-xxx
c0f573d3-9b46-4af5-8792-989c6f48b91e:0.0 auto-del excl
bash$ python test.py
Reply address: amqp://
127.0.0.1:5673/ec940df5-4882-455a-bc14-49b2fb2c8ae1_receiver-xxx
Response: 'proton rocks'
[davin@laptop24 proton-scm]$ qpid-config -a 127.0.0.1:5673 queues
Queue Name Attributes
======================================================================
23e5aa68-aa52-4de4-b8fa-14c732f854a8:0.0 auto-del excl
9795cd4c-4d24-42f1-b369-dca989345467_receiver-xxx
ec940df5-4882-455a-bc14-49b2fb2c8ae1_receiver-xxx
If only there is a way to set the dynamic flag on the terminus for the link
at the Messenger level as I think that would add the auto-del attribute to
the queue. I think this is possible if I were using the proton Engine
rather than the Messenger
and I tried to piece together what I need to do from studying the code
found in proton.c, but the send loop in that code gave me a headache. I
think we just allow Messenger to set that dynamic flag when a subscription
is requested, I could use Messenger and be golden, so if I have a feature
request, that would be what I want. Messenger is built on Engine, Engine
has the ability to set the dynamic flag, what's needed is to expose that
feature in Messenger. It's all proton, all AMQP 1.0, what's not to like?
On Fri, Jan 10, 2014 at 8:01 AM, Gordon Sim <g...@redhat.com> wrote:
> On 01/10/2014 09:15 AM, Fraser Adams wrote:
>
>> I'm much more familiar with qpid::messaging/JMS myself and I'd be quite
>> keen for some guidance on AMQP 1.0 Addressing and examples of say how to
>> write something in messenger that could publish or subscribe to things
>> that I'm familiar with - most of my current use cases publish to
>> amq.match - the default headers exchange and subscribe by using
>> x-bindings. Over time I'll migrate to message selectors, but in the
>> short term I'd love to know how to go about getting this stuff
>> interoperable.
>>
>
> At present messenger only sets the address of the source for receiving
> links and of the target for sending links. For sending/receiving to an
> existing queue or to a fanout exchange, this is all you need (just specify
> the queue or exchange name as the path in the url of the address used, e.g.
> amqp://127.0.0.1/my-queue or amqp://127.0.0.1/amq.fanout). That gives you
> the basic queue and topic patterns of JMS.
>
> Binding a subscription to the headers exchange (or indeed even to topic
> or direct exchanges) with both qpid brokers requires using the 'legacy
> amqp' filters registered as extensions for 1.0. Likewise if specifying a
> jms selector. At present there is no way to set a filter on a source when
> using messenger however.
>
> To migrate from using the headers exchange to using a selector while
> retaining the qpid::messaging API should be fairly straightforward. You
> just need to specify a 'selector' option in the link properties for your
> address, and use e.g. a fanout exchange instead.
>
> e.g. drain -f "amq.fanout; {link:{selector:\"colour IN ('red', 'blue')\"}}"
>
> then:
> spout amq.fanout -P colour=red
> spout amq.fanout -P colour=yellow
>
> etc.
>
> That gives you the same functionality as the headers exchange in (I think)
> a much simpler syntax, and works for both 1.0 (where it uses the registered
> jms filters extension) or 0-10 (or mixtures of the two).
>
> You can use another exchange type as well of course, with additional
> filtering on subject distinct from the selector.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
--
Davin Shearer
Engineer
8830 Stanford Blvd, Suite 306
Columbia, MD 21045
443-741-4517
