qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: I seem to be getting spurious exchangeDeclare Events as a result of sending to a replyTo address.
Date Mon, 22 Aug 2011 18:20:26 GMT
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 <gsim@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


Mime
View raw message