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