If I'm subscribing to a node named "#" doesn't it make sense that the terminus be marked dynamic automagically?
On Fri, Jan 10, 2014 at 9:26 AM, Shearer, Davin <[email protected]>wrote: > 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 <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Davin Shearer > Engineer > > 8830 Stanford Blvd, Suite 306 > Columbia, MD 21045 > > 443-741-4517 > -- Davin Shearer Engineer 8830 Stanford Blvd, Suite 306 Columbia, MD 21045 443-741-4517
