qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Address of default no-name exchange
Date Mon, 04 Jul 2011 09:27:10 GMT
On 07/03/2011 08:22 AM, Jiri Krutil wrote:
>>> Let's say I'm writing a service processing requests coming from
>>> different clients, each request having a different reply-to address. To
>>> be able to send the responses, do I have to create a new Sender for each
>>> request? If creating a Sender means a sync roundtrip to broker, won't
>>> this kill my performance? Surely there must be some way how to send the
>>> requests async? (without explicit bindings to the response queues)
>>
>> Yes, I agree that in that use case it would be useful to bypass the
>> passive declare. Perhaps an overloaded createSender() with an explicit
>> sync flag?
>>
>> Having a pseudonym for the default exchange might also address your
>> original aim to create a sender to that exchange. My concern there is
>> whether that would be relevant outside the specific protocol
>> version(s) defining such an exchange.
>>
>> I think the fully async creation of senders is a nicer solution.
>> Thoughts?
>
> I think both would be useful.
>
> In some scenarios the list of exchanges is statis and people tend to
> manually pre-configure durable exchanges and don't declare anything
> programmaticaly on run time. In such case you would prefer an async
> version of createSender() that does not check if the exchange is there.

Even if the exchange is pre-configured, verifying that the address used 
to create the sender matches an existing configuration can be useful and 
helps catch setup errors early.

However, I agree that there are cases where you may want to go 
asynchronous (as in your example).

> Being able to address the default exchange would be great. Unless there
> is some strong technical reason against it, I think it should be
> possible. It is the typical thing you want in a request-response
> messaging pattern, where you do *not* want to verify if the reply-to
> queue exists or not.

I think in the general request-response case you want to allow for any 
address, including those that involve another exchange. So to me, using 
a sender to the default exchange is a special case.

> What if you just allowed the Address name to be empty and let it
> represent the default exchange?

I prefer something a little more explicit, e.g. a special name 
(qpid.all-queues). An empty name would look too much like a syntax error 
and is also too closely tied to a detail of a particular protocol version.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message