2008/10/1 Gordon Sim <[EMAIL PROTECTED]>: > 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. >
The exchange to which temporary queues are bound should already be configurable... That I don't have a problem with. -- Rob
