[
https://issues.apache.org/jira/browse/QPID-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13630052#comment-13630052
]
Chuck Rolke commented on QPID-4720:
-----------------------------------
The correct behavior is to match values when they are compatible.
Research into moving Headers exchange match to use the Selector comparison
logic reveals that Headers exchange is *already* using logic that is correct.
When the code was refactored in August, 2012, the mission code moved to a new
Matcher logic that solves the original complaint but the self tests still use
the old logic.
With only minor changes a new match function could be developed. This version
of match is then called by mission code and by self tests. The old version of
match and its supporting code is to be deleted.
> C++ Broker Headers exchange match comparison issue with value types
> -------------------------------------------------------------------
>
> Key: QPID-4720
> URL: https://issues.apache.org/jira/browse/QPID-4720
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.20
> Reporter: Chuck Rolke
> Assignee: Chuck Rolke
>
> Steps to Reproduce:
> 1. Use the old Python client API and do this:
> session.exchange_bind(exchange="MyHeadersExchange", queue="MyQueue",
> arguments={"x-match":"all", "MyHeader":1})
> 2. Use the new C++ messaging API to send a message like this:
> Message msg(;
> msg.getProperties()["MyHeader"] = boost::uint16_t(1);
> 3. Use qpid-stat to see if the exchange routed the message to the queue, or
> if it was dropped. In this case, it will be incorrectly dropped.
>
> Actual results: Message is dropped
> Expected results: Message is delivered into queue MyQueue
> Additional info: It looks like the binding generated via Python is a match on
> the value 1L. If we create a C++ client to set up the binding, it creates a
> match based on 1. It looks like the headers exchange thinks that 1 (2-bytes)
> isn't the same as 1L (4-bytes).
> ----------
> Headers exchange looks at the value type and sees that they are different and
> so does not compare the value data.
> I'm comfortable saying that the comparison is based on the header entry's
> type and data value. If the types don't match then the comparison fails. This
> is how the code works now.
> To match "comparable" data types then the match must cover [int uint]_[8 16
> 32 64], and possibly float and double. Even a string data type could be
> matched "1", "0x1", and so on. This could be an awful lot of development
> effort and testing.
> What is the correct behavior?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
