Re: Address of default no-name exchange

[Jiri Krutil <ji...@krutil.com>]

>> 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.

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.

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


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

Re: Address of default no-name exchange

[Gordon Sim <gs...@redhat.com>]

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