On 12/18/2014 01:46 PM, Robbie Gemmell wrote:
On 18 December 2014 at 12:29, Gordon Sim <g...@redhat.com> wrote:
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 client).
Mostly in that case, but not always. There might be only one "foo"
that exists when they reply, but it might not be the correct type of
"foo" any more.
Warning, completely contrived example: An application sets JMSReplyTo
to a Queue "response" that currently exists and then sends it to the
"request" queue. Message sits on "request" Queue for a while. Someone
decides to delete the "response" Queue because they think they are
done with it. Someone else creates a "response" Topic. A client which
doesnt understand the annotations/capabilities consumes the message
and proceeds to created a producer and reply to "response". That
message is going to end up in the wrong place if we rely on the
address, since it will match but the missing annotations/capabilities
would have told us it isnt the correct destiantion.
It is indeed a contrived example, and one that wouldn't work anyway. It
doesn't seem more wrong to me under those circumstances that the message
goes to the newly created topic than that it got dropped or a sender to
the address could not be created. (If anything it seems better and more
adaptable to be able to change the configuration of a node, and the
topic v. queue thing is to be just an extreme reconfiguration).
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.
I dont like it either, but as the spec only gives one namespace and
JMS requires multiple spaces I dont see another way which works.
I don't think it actively requires distinct namespaces. The
'recommended' approach with JMS is to use Destinations retrieved by a
logical name from JNDI.
Setting up both a queue and a topic with the same name is possible, but
not in my view required.
To be clear, I'm not saying there shouldn't be a good solution for the
(I believe very rare) cases where that is unavoidable. There should be.
I'm just saying we shouldn't take the type split address space as an
accepted norm for AMQP.
It
would have been nice if the core 1.0 spec handled this 'type' in some
way. It does for the message transfer formats for example, just not
for the things they are being sent to.
JMS does have the different types, and expects them to behave in
certain ways. For a JMS applications behaviour to be affected such as
in that contrived example above is also not very nice.
For that particular example, I don't think it matters much. Personally I
would in fact prefer to be able to redefine a node that was previously a
queue to be a topic (or to be some hybrid).
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.
In the JMS case I think there will always be ambiguity without a
naming scheme and/or metadata.
I'm not sure what you mean there.
As I have said before in other
contexts, if the application wants to use a JMS Topic "foo", it would
preferable it didnt get attached to a Queue "foo" because that
happened to be there.
Right, that I agree with. That to me is simply about asserting that the
capabilities you expect/require are in fact in place. (I do think it
should also be possible to have clients/applications that don't care).
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.
In addition to allowing the client to optionally assert it is getting
the behaviour it wants, creating nodes on demand is another reason we
defined capabilities for the different JMS destintion types (needed
for temporary queue vs topic, but useful for queue vs topic if the
broker supports auto-creating those with arbitrary addresses).
I don't object to the capabilities. They seem very much in keeping with
the intentions of the spec and can be more broadly utilised. (Indeed
qpidd recognises those two capabilities already).
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).
This is true. I was speaking about the client, I didnt mean to suggest
additional steps wouldnt still be needed for the broker.
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).
As above, I dont think there is a non-ambugious case for JMS.
I disagree.
I also
dont mean to suggest the example cant have configuration so a user
could e.g use it with a different queue they already had rather than
create a new one, just that it would be nice if they didnt almost
always have to actually configure it.
I agree. However I would rather tackle that at its root, by trying to
build some consensus and eliminating the differences in broker behaviour.
Having optional workarounds to paper over the differences is fine, but
baking that into the standardised mapping seems to me to be not just
condoning, but encouraging a distortion of the model purely for
expediency in JMS (without to my mind much *real* benefit even there).
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.
I would say this is a normal behaviour for JMS, not really a corner case.
You think it is normal to have a queue and a topic of the same name?
I don't think I have ever seen such a system where that wasn't
considered a misconfiguration (that was causing confusing regardless of
whether these were unambiguously addressed at the protocol level).
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
specification.
I think it solves the problem if you use it (or will do if we
incorporate the white/blacklisting idea in some way to prevent messing
with certain addresses), it would just be nice if it was slightly
slicker.
The old client wont work against 2 of our 4 brokers without
configuring that. Due to its heritage, the new client currently has
its prefixes defaulted to work with one of those brokers, and so it
will behave oddly or not work against the 3 others unless it is
reconfigured.
Adding a mechanism to convey the prefix automatically was simply a way
to avoid such hassle in some cases, and in others it wont be used and
would thus have no effect (potentially at the expense of needing to
ensure applications dont use JMS queues and Topics with the same
name).
As above, I don't object to an optional extension that defines a
mechanism for prefixing. However I don't think it should be required or
encouraged as the 'right' way.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
