qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: I seem to be getting spurious exchangeDeclare Events as a result of sending to a replyTo address.
Date Tue, 16 Aug 2011 11:37:56 GMT
On 08/14/2011 08:47 PM, fadams wrote:
> Hello all,
> In a JMS client I've created an address string of the form:
>
> qmf.default.direct/qmfc-zappa.17410
>
> and used this to create a reply address:
> replyAddress = syncSession.createQueue(address);
>
> which is then used in various request/response patterns e.g. in my request
> messages I do:
>
> request.setJMSReplyTo(replyAddress);
>
>
> In another application in a MessageListener I get the replyTo via
> destination = message.getJMSReplyTo()
>
> then sent a response to the original requester via:
>
> requester.send(destination, response);
>
>
> But I've noticed as I've been monitoring QMF Events that I'm seeing
> exchangeDeclare Events. There appears to be an Event corresponding to each
> call to send.
>
>
>
> This doesn't seem right to me. Is there a good reason for this, or is it a
> bug? All these exchangeDeclares can't be good for the performance of
> request/response invocations.

I believe the issue here is that the destination is validated before the 
message is sent, and that involves an exchange declare.

If you used the same Destination object, the validation would only 
happen once. However if each send is using a different Destination 
instance then each send will validate the destination.

There appears to be some caching logic internally, the purpose of which 
I believe is to try to ensure the Destination returned from 
getJMSReplyTo() is the same instance where possible. However it looks to 
me like there is a bug in that.

In org.apache.qpid.client.message.AMQMessageDelegate_0_10 the 
getJMSReplyTo() method uses the ReplyTo obtained from the incoming 
message. However no overridden definition of equality is defined for 
that class so each instance will be treated as a distinct key. As far as 
I can see the cache is therefore useless on the 0-10 codepath.

I think this *is* a bug in other words. Anyone disagree? Am I missing 
something?

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


Mime
View raw message