Robert Godfrey wrote:
2008/9/30 Rajith Attapattu <[EMAIL PROTECTED]>:
Hi Qpidians,
Currently our temp queue naming is hard coded to "Temp_ " + uuid.
We could change this to a format that is configurable and captures more
useful information that can be utilized by,
I think there are different point in here:
1) Should we change our temp queue naming to include more useful information
+1 from me
2) Should we add some sort of way for the client application to
configure the scheme for naming temporary queues created from JMS
-1 From me (I have no problem with the low level API allowing any name
to be used)
I tend to the opposite view! My 'theory' (vague as it is) is that it
should be possible to use the JMS API but have flexibility in how those
actions are 'mapped' into AMQP. (The name of the queue is interesting,
but actually the exchange and binding details are in AMQP terms more
valuable).
My fundamental objection to configurability is that the client
applications shouldn't need to know how these queues are named and
that allowing them to configure it is to risk them building in
dependencies on behaviour we may not be able to maintain in the face
of changes to the underlying AMQP model.
I agree that the clients themselves most likely don't care and they
should be able to work without any further thought.
There may be reasons for adjusting the underlying system configuration
though, and allowing for that seems reasonable to me.
Obviously any configuration or code that relies on a particular aspect
of AMQP becomes dependent on that aspect and at risk from alteration or
removal of that aspect by subsequent revisions to the specification.
At present I can create my own AMQDestination instance and that is
usable from JMS clients for publishing to or consuming from. I may
construct it to use a particular AMQP 'routing scheme'. By doing so I am
becoming dependent on some aspects of the AMQP protocol. There is
certainly risk there and we should advise carefully, but I don't think
we should prevent that.
Allowing the strategy by which the AMQDestination constructed for a
temporary queue is a further step along that path in my view.
The alternative to configuration is to say either that a user cannot
change how some of the more arbitrary decisions in the JMS client work
or they have to write code to explicitly do what they want in AMQP terms
(whether through Qpid extensions or another API). Moving this to
configuration shields the application code from changes (which is still
dependent on those features but should be easier to change for alternate
deployments).
From a broker point of view we cannot depend on any naming scheme
since the names are client generated and thus non-Qpid clients may be
being used to connect to the broker (a use case for this functionality
as put to me involved being able to detect from the name that a
particular reply-to address related to a temporary queue).
What is the use case for a client being able to configure the naming scheme?
As above, I think that where there are reasonable choices in how JMS is
mapped to AMQP, making that mapping customisable is in general valuable.
However as a motivating example, I might want a 'federation' where the
relaying of messages between brokers in that federation is controlled by
the exchange to which they are published.
Some clients may need to use a 'service queue' that I then want to be
offered by another client on a remote node of the federation. So I want
the queue used to communicate with that 'service' to be configured to
use an exchange specifically setup for inter-broker routing, and in
addition have the clients that use it have temporary queues that will
work across the federation also.
By picking the exchange name and binding key used I can configure my
system to work in this federated manner without changing my client.
