[ 
https://issues.apache.org/jira/browse/QPID-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chuck Rolke resolved QPID-4720.
-------------------------------

       Resolution: Fixed
    Fix Version/s: 0.23

Fixed at Committed revision 1477317.

Bug with comparing float types tracked in QPID-4740.
                
> 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
>             Fix For: 0.23
>
>
> 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

Reply via email to