Jonathan Robie wrote:
That's how the examples in other languages work - there is a separate
program that sets up the configuration, a publisher that sends messages,
and a consumer that reads messages from a queue.
Private queues (exclusive + autodelete) are treated differently, the
client configures these queues and the associated bindings, even though
the queues live on the broker. And these queues rather belong to the
client - I assume we want to make sure the client can configure them. In
other languages, I imagine they just use the configuration API for this.
What's the best way to handle this in Java JMS?
It depends what the private queues are used for. If they're for topic
subscriptions then that is done under the covers for both JMS and the
other clients and so wouldn't need to explicitly be part of the API. If
they're for temporary queues then JMS has a specific API for creating
temporary queues and temporary topics.
The other APIs will probably do temporary queues as part of the options
associated with an address/destination. This would permit some more
flexible configuration in Java via JNDI, which is ok in this particular
case since the lifecycle of the queue is tied to the lifecycle of the
client, so there is a reasonable way to delete these, and the queues are
also owned by a single client so there isn't the race condition issue.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
