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:[email protected]
