qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jiri Krutil <j...@krutil.com>
Subject Re: Address of default no-name exchange
Date Sun, 03 Jul 2011 07:22:31 GMT
>> 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

View raw message