qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: JMS Destination handling for AMQP 1.0
Date Thu, 18 Dec 2014 12:29:06 GMT
On 12/17/2014 12:37 PM, Robbie Gemmell wrote:
> Hi everyone (please use reply-all to keep both lists on the trail),
> I would like to have a discussion around JMS destination handling in
> the JMS Mapping for AMQP 1.0, in particular around how to handle JMS
> Destination names via the AMQP "address" field of a link
> (producer/consumer) source/target and the "to", and "reply-to" field
> of messages.
> Apologies for the length of the mail, there is a fair bit to outline.
> I moved some information for full context to the end to help a tiny
> bit.
> JMS defines multiple Destination types that each have their own
> inherent name space, so it is possible for example to have a Queue and
> a Topic with the same name (e.g "foo"). AMQP defines an "address"
> field on the source/target of links (producers/consumers), and a "to"
> and "reply-to" field are available on messages, to indicate the
> destination node (e.g queue/topic) address. These are typically string
> values, and they form a single space since as there is no additional
> node type information only the address name itself.
> This is is mostly an issue for non-temporary Queues and Topics since
> TemporaryQueue and TemporaryTopic destinations will be given generated
> addresses by the 'broker' peer through use of dynamic nodes, and so
> can naturally be prevented from having the same addresses as each
> other, and be made unlikely or unable to clash with non-temporary
> nodes.
> To handle this mapping between JMS and AMQP it would seem we must either:
> 1. Not support JMS Queues and Topics with the same name existing at all, OR
> 2. Allow multiple nodes to have the same address string but use type
> metadata (via capabilities + annotations, see additional context) to
> discriminate between them, OR
> 3. Utilise address string naming conventions (e.g prefixes) for them
> to separate the types into subspaces.
> The first option is an issue for implementations that already do, and
> wish to continue to, allow Queues and Topics with the same name via
> other protocols while also supporting AMQP, and would be a limitation
> in terms of full JMS support. The second option would break reply-to
> usage for any clients or intermediaries that don't understand the
> message annotations and/or source+target capabilities carrying type
> metadata (see additional context).

Only in the case that the node name is ambiguous though, right? I.e. 
only if there exists both a queue and a topic with the same name. 
(Intermediaries shouldn't need to care, providing the annotations are 
defined such that they can be passed on without understanding them which 
they would need to be anyway for correct JMS behaviour at the receiving 

I don't really like dividing the namespace by type. Many applications 
shouldn't need to care about the type. Having to change the node name to 
get a different behaviour, rather than just changing the configuration 
of that node seems undesirable to me, at least for some cases.

While I wouldn't necessarily object to use of address prefixes in cases 
where disambiguation is needed, I would be disappointed if that were to 
become the accepted or even 'blessed' pattern.

If a broker receives an attach to/from a node 'foo' and there is either 
a queue or a topic of that name (but not both), I think they should 
resolve the name to that existing entity. They should not *require* you 
to specify a prefix when there is no ambiguity.

A further complication is where nodes are created on-demand as attach 
requests are made. However in this case the broker can provide the means 
to define patterns allowing particular node names to be matched to 
desired policy.

> The third option either requires
> clients to always utilise the full address strings in
> session.createQueue("<queue-prefix>foo") etc calls, or providing a
> means to configure the prefixes within the client so that they are
> added/removed behind the scenes and the application just uses
> session.createQueue("foo"), but the resulting AMQP address string
> would be "<queue-prefix>foo". The main issue with requiring clients
> always use the full address as the session.createQueue(..) value would
> be for bridging between different systems using different conventions,
> though the values for those methods are noted as being
> provider-specific.
> Both the old Qpid AMQP 1.0 JMS client, and the new JMS client we are
> creating that implements the JMS Mapping for AMQP being worked on,
> currently do some form of the third option, providing a way to
> configure a 'queue prefix' and 'topic prefix' that are used to prefix
> the application provided strings in session.createQueue(..) etc for
> outgoing addresses used for links and messages and be stripped from
> incoming addresses on messages to give the names used for the
> JMSDestination and JMSReplyTo objects. Temporary destinations are
> named by the 'broker' peer and their addresses are used as provided.
> The main issue with this approach is that such configuration makes it
> more difficult to use the client against a number of different
> brokers, which is a goal, since this configuration is likely to differ
> between them meaning even the simplest HelloWorld type example may be
> unable to work against them without additional configuration.

Even the simplest example may require some configuration of the broker 
in the form of creating the required queue/topic (unless they are 
created on-demand).

If brokers can handle the non-ambiguous case without prefixing, which I 
think is the ideal, then simply configuring the broker for the name used 
by the example should be sufficient. (In fact having the name the 
example uses be a command line option would also make sense, making 
adaptation even easier).

> Between
> ActiveMQ and Qpid we currently appear to have 3 different options for
> our brokers (two different prefixes being required, or it being
> optional [at the cost of being unable to support Queues and Topics
> with the same name]), and considering others would likely expand this.
> An idea to handle this was to have the brokers use connection
> properties to inform the client of the prefixes (if any) they require
> it to use, allowing different brokers to supply their own specific
> value (if any) to meet their requirements, and allowing clients/simple
> applications to work against many of them without further
> configuration change.
> An alternative suggestion was to have the JMS Mapping define a set of
> standard name prefixes the client would use by default, such that the
> issue of Topics and Queues with the same name is addressed by the
> mapping, while also allowing brokers to specify their own values via
> connection properties so that their specific needs can still be met if
> different (e.g they have existing naming conventions they wish/need to
> retain).
> There was also a suggestion that something beyond a simple prefix may
> be needed, I will let the person behind those thoughts expand further
> to stop this getting any longer for now.
> Thoughts?

I think 'recommended' practice should be to avoid ambiguous node names.

I accept of course that we have to be able to cope with the situations 
where they exist (this is the case for brokers built around the pre 1.0 
AMQP model of exchanges and queues also). These should be seen as 
workarounds corner cases however, not standardised as 'normal' behaviour.

Personally I think the behaviour you describe already in the JMS clients 
- the ability to configure the client to use prefixing - is sufficient. 
I don't think it needs to be something blessed by the AMQP mapping 

I would rather see the end user experience switching between brokers 
improved by growing consensus on (configurable) node resolution than 
have an additional standard that tries to paper over differences.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message