On Mon, Oct 17, 2011 at 5:54 AM, Robbie Gemmell
<[email protected]> wrote:
> Why do we resolve Address node types? This question arose during
> review of proposed updates to the Address syntax implementation for
> the Java client, but ultimately looks to be a wider question for all
> the clients and so I am asking it here outwith that review.
>
> The documentation for the Address syntax on the Qpid and MRG websites
> states that nodes can be specified as Queues or Topics, but that nodes
> are Queues by default.
Throughout my reply the word 'node' means Queues & Exchanges in 0-10 speak.
The default applies when the node referred to by the address name does
not exist and the client has received instructions to create it.
(The documentation does have a lot of gaps and that's a all together a
separate discussion :) ..)
> It appears that the clients (at least the Java
> one) instead ignore that statement and decide that if the user hasn't
> specified a type then it should decide one for them, querying the
> broker and figuring out whether there is a Queue or Exchange with the
> node name and then picking Queue or Topic as the node type depending
> on which exists (or throwing an exception if both do because the type
> is ambiguous).
In general applications should not be creating nodes (Queues &
exchanges in 0-10 speak) in the broker.
Therefore when an address is given, the client will attempt to verify
the existence of the node referred by the address name.
It also important to figure out what type of a node if the type is not
explicitly specified.
This makes it easy for applications to specify addresses, as in most
cases and address is simply a "name".
The "type" is important as it helps to figure out if it's a Queue or a Topic.
As the semantics differ based on the type.
> I would like to understand why this auto-resolving behaviour was
> introduced. I believe that this needs to be removed from the Java
> client entirely so that we can properly implement the Destination
> hierarchy and provide an implementation to our users which actually
> lets them use all of the JMS API easily. I would also argue it should
> be removed from any of the other clients that are doing it due to the
> behavioural ambiguities it seems to introduce.
>
>
>
>
> For those wanting more of a read, here is some further elaboration to
> the above (since the email got a lot longer than expected :D)
Appreciate you taking the time to elaborate on your concerns. :)
> In reviewing the proposed changes, Alex and I noted that it opened
> possibility for creating Destination objects that don't implement
> either the Topic or Queue interface, and instead use isTopic() and
> isQueue() methods to check the answer against delegates which do
> implement them. Rajith responded to our query on this that it was
> because when creating an Address syntax based Destination from a
> String, you cant tell what type of node it is until it is later
> resolved against the broker.
I think this was more of an issue with my implementation rather than a
design issue with the addressing syntax in general.
If we attempt to resolve the destination early, rather than when it's
used to create a consumer or a producer we can solve this issue.
Lets look at the two cases where destinations are created/retrieved.
1. When creating queues/topics directly using the session.
We need to resolve the address and verify the name supplied before the
method returns.
Ex ssn.createQueue(String name) & ssn.createTopic(String name)
Currently my patch doesn't do that and if that is implemented then we
guarantee that the Object returned is indeed representing a 'Queue' or
a 'Topic' on the broker (not just implementing the jms interface).
2. Specifying addresses in the JNDI file.
As you correctly pointed out this becomes an issue when we create
destinations from the jndi file.
As in this case when an application performs Destination dest =
(Destination)ctx.lookup("my-dest"), we are unable to return a
javax.jms.Topic or javax.jms.Queue implementation bcos we don't know
the type unless explicitly specified.
*** Perhaps this maybe the very reason why in JMS 1.1 they introduced
the generic Destination interface.***
Off the top of my head, I see two solutions to this.
(a) . The users needs to explicitly specify the "type" when they
specify addresses in the jndi file. And we use that to return a
destination object that works specifically with the Queue or Topic
interface.
(b.1) Or not use the JMS 1.0 interfaces (which requires the
specialized Queue or Topic interfaces) if a type is not specified.
Obviously if they attempt to use a destination impl which
simply implements the generic interface with the JMS 1.0 interfaces
they would get a class cast exception.
Please note The JMS 1.1 interfaces will work correctly with
the generic Destination interface.
(b.2) Another solution would be something akin to the
AMQAnyDestination (not a big fan of this). That is the
AddressBasedDestination implements both the Topic & Queue interfaces
allowing it to be passed into the JMS 1.0 interfaces and inside those
method implementations we perform a check to see if they are indeed
Queues or Topics by resolving an returning the correct
AddressBasedTopic or AddressBasedQueue destination for the methods to
work with.
There maybe more elegant solutions to this problem. I need to think a
bit more here. But I'm sure we can come up with something better.
> This is troubling for various reasons, e.g. that it makes the code
> uglier,
This can be worked out. As I mentioned the proposed changes is the
first step in a series of patches.
I think we can do better with the code to make it less ugly and I'm
experimenting to get there.
> and then the slightly more pressing issue that it means it
> wont be possible for users to use the majority of the JMS API with the
> destinations they create from JNDI since many of the methods require
> destinations which implement the Queue or Topic interface and not just
> the super Destination interface.
Again I'd like to draw your attention to the distinction between JMS
1.0 and JMS 1.1 interfaces.
The JMS 1.1 interfaces will work very well with the generic
javax.jms.Destinaitons.
And by using the solution I outlined above we could ensure we provide
the specialized interfaces required by the 'older' JMS 1.0 interfaces.
> This behaviour seems highly undesirable to me, as in addition to the
> design related issues discussed above that it provokes that sparked
> the question, it simply seems unreasonable that we should be making
> those decisions for the user (especially since we have documented that
> we don't). This auto-resolution system also seems to open the
> possibility of one users configuration unwittingly altering the
> behaviour of another users application e.g. by creating an Exchange
> with a given name later on, causing another users code to switch
> without their consent from using Queues which might have been
> auto-delete to using Topics, or by creating an Exchange where a Queue
> with the same name already exists and causing another users client to
> throw exceptions it didn't previously because the type can no longer
> be auto-resolved. It also isn't clear how this is meant to interact
> with the 'assert' functionality; surely we will sometimes be able to
> pass an assertion for a decision we made, even if that isn't what the
> user code used to be asserting against?
>
> Furthermore, it has been pointed out on the user list that this type
> of querying can be a point of performance degradation, forcing (it
> doesn't seem to be configurable?) the client to somewhat needlessly
> round-trip to the broker in many cases it doesn't seem necessary.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:[email protected]
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
