You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by fadams <fr...@blueyonder.co.uk> on 2011/08/14 21:47:54 UTC
I seem to be getting spurious exchangeDeclare Events as a result of
sending to a replyTo address.
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.
Regards,
Frase
--
View this message in context: http://apache-qpid-users.2158936.n2.nabble.com/I-seem-to-be-getting-spurious-exchangeDeclare-Events-as-a-result-of-sending-to-a-replyTo-address-tp6685560p6685560.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: I seem to be getting spurious exchangeDeclare Events as a result
of sending to a replyTo address.
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Robbie that's good news.
Did you see my later post? I'd be interested in yours (and others) view
on the following "
I'm curious though. What's the reason for validating a replyTo address using
an exchange declare? What I mean by that is that I'd have thought that in
general a reply to address gets sent by a producer client as its return
address and in the normal case this address would be a valid one that the
producer has added on to the request message it has sent.
Now clearly it's possible for that address to not be valid either through
accident, long time lag between request/response or something malicious -
but isn't that an exception condition? So what would happen if the
validation didn't take place? If the replyTo message gets sent to an invalid
address won't that simply result in an exception from the broker? Surely
given that the normal condition is that the address actually exists it's
wasteful to do a validity check that costs an exchange declare and it's
better to get an exception in an exception condition.
Have I missed something subtle?
"
Robbie Gemmell wrote:
> Agreed, that is a bug and the cache is useless (harmful even) as a
> result. I have raised a JIRA
> (https://issues.apache.org/jira/browse/QPID-3440) for it and attached
> a patch with a test to detect it, and update the transport code
> generator to fix it.
>
> It hasnt been applied yet though, because it leads to a subtle change
> in behaviour of returning a different object type to represent the
> replyTo Destination than previously which leads to breaking another
> test, sigh. Need to investigate that further before applying the
> patch.
>
> Robbie
>
> On 16 August 2011 12:37, Gordon Sim <gs...@redhat.com> wrote:
>
>> 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
>
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: I seem to be getting spurious exchangeDeclare Events as a result
of sending to a replyTo address.
Posted by Robbie Gemmell <ro...@gmail.com>.
Agreed, that is a bug and the cache is useless (harmful even) as a
result. I have raised a JIRA
(https://issues.apache.org/jira/browse/QPID-3440) for it and attached
a patch with a test to detect it, and update the transport code
generator to fix it.
It hasnt been applied yet though, because it leads to a subtle change
in behaviour of returning a different object type to represent the
replyTo Destination than previously which leads to breaking another
test, sigh. Need to investigate that further before applying the
patch.
Robbie
On 16 August 2011 12:37, Gordon Sim <gs...@redhat.com> wrote:
> 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
Re: I seem to be getting spurious exchangeDeclare Events as a
result of sending to a replyTo address.
Posted by fadams <fr...@blueyonder.co.uk>.
Thanks for the update Gordon - glad I'm not imagining things :-)
I'm curious though. What's the reason for validating a replyTo address using
an exchange declare? What I mean by that is that I'd have thought that in
general a reply to address gets sent by a producer client as its return
address and in the normal case this address would be a valid one that the
producer has added on to the request message it has sent.
Now clearly it's possible for that address to not be valid either through
accident, long time lag between request/response or something malicious -
but isn't that an exception condition? So what would happen if the
validation didn't take place? If the replyTo message gets sent to an invalid
address won't that simply result in an exception from the broker? Surely
given that the normal condition is that the address actually exists it's
wasteful to do a validity check that costs an exchange declare and it's
better to get an exception in an exception condition.
Have I missed something subtle?
Regards,
Frase
Gordon Sim wrote:
>
>
> I believe the issue here is that the destination is validated before the
> message is sent, and that involves an exchange declare.
>
>
> I think this *is* a bug in other words. Anyone disagree? Am I missing
> something?
>
>
--
View this message in context: http://apache-qpid-users.2158936.n2.nabble.com/I-seem-to-be-getting-spurious-exchangeDeclare-Events-as-a-result-of-sending-to-a-replyTo-address-tp6685560p6700090.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: I seem to be getting spurious exchangeDeclare Events as a result
of sending to a replyTo address.
Posted by Gordon Sim <gs...@redhat.com>.
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