On 18 December 2014 at 15:10, Gordon Sim <g...@redhat.com> wrote:
> 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).
To me it does, I would expect creation of the sender to fail (thats
why I put that step in instead of saying just 'send the message') or
the message to be rejected.
>
>>> 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.
Ok, shall we instead say it is allowed and people sometimes use it.
JNDI vs non-JNDI isnt doesnt really change this, since the JNDI lookup
name is distinct from the provider-specific destination string (which
is a large part of the reason it is 'recommended' to use JNDI, I
believe).
>
> 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.
I mean the node address isnt always sufficient to indicate what type
of node it is is.
>
>> 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).
>
That is one of the reasons they were chosen :)
>
>>>> 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).
>
I am not saying I would do it personally, but I have seen it done yes.
>>> 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.
>
It was always intended to be an optional mechanism. I definitely dont
want to define a requirement for prefixing or a mandated prefix in the
JMS mapping, I dont feel that we can do that.
I am now inclined to treat anything we do in this area an
implementation detail, much like JMS does itself for naming (and I
guess the AMQP 1.0 core protocol also), rather than define it in the
mapping.
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
