Thanks for the detailed response. That makes a lot of sense. Can you (or anyone) point me to a good document describing the 'link' and 'node' option specification and potentially some more examples?
Tell me if I have this correct: The address field you used creates a sender using AMQP 0-10 protocol and will send with a default subject of 'news.world'. Consequentially, because of the 'link' options, it will also create a queue named 'worldnews' with a subject subscription (or routing key binding?) to 'news.world'. This queue will be persistent even when this sender disconnects and other senders/receivers can connect to it also. -Chris On Mon, Jun 9, 2014 at 5:26 AM, Gordon Sim <[email protected]> wrote: > On 06/06/2014 03:11 PM, Chris Wj wrote: > >> Yes, competing for messages, like a task queue with multiple workers. >> >> I want to have N workers. Any worker knows how to process M kinds of >> messages (identified by subject, or queue name). For now, N = M, but I >> foresee that it will not in the future. I want to make sure I can enqueue >> a >> job with highest priority that will be taken by the next available worker >> for that subject. The subjects wont be changing often. They are categories >> that we can manage over time. Having dynamics subjects would be great, but >> we can manually create a queue for a subject if need be. >> > > Manual configuration is usually the most portable option. However if you > keep your sender and receiver addresses configurable, then its easy to > adapt. > > To have a shared queue created (and bound) on-demand, shared by multiple > receivers and not deleted when there are no receivers, you could use > something like the following with your receivers: > > 'amq.topic/news.world; {link:{name:worldnews, > x-declare:{auto-delete:False, exclusive:False}}}' > > on the sending side you can then send either to amq.topic, setting the > subject of messages as desired, or if you like you can create a sender of a > specific subject e.g. amq.topic/news.world and it will set the subject for > you by default. > > Now, when you say 'forward compatible', my one concern is that at present > the pure python qpid.messaging library is AMQP 0-10 only. That pretty much > limits it to one of the Qpid brokers. > > There is a swig wrapper for the c++ version of that api that is very > close. We use it for testing as it can speak either 0-10 or 1.0. > > Ideally for forward compatibility, you would want something that can speak > AMQP 1.0. Not because the 0-10 support is going to be removed, but because > it gives you more options. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
