Bug 468026

Summary: Problem in FieldTable encoding of doubles
Product: Red Hat Enterprise MRG Reporter: Matthew Farrellee <matt>
Component: qpid-cppAssignee: Gordon Sim <gsim>
Status: CLOSED CURRENTRELEASE QA Contact: Kim van der Riet <kim.vdriet>
Severity: high Docs Contact:
Priority: high    
Version: 1.0CC: eallen, freznice, jsarenik, matt
Target Milestone: 1.1   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-03-20 08:08:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matthew Farrellee 2008-10-22 13:56:40 UTC
On the producer side (C++) a FieldTable::setDouble(..., double) is called, e.g. setDouble("CURRENT", 3.000000)

10/22 09:44:05 Limit: b; Current: 3.000000, Max: 3.000000
10/22 09:44:05 Limit: c; Current: 3.000000, Max: 3.000000
10/22 09:44:05 Limit: a; Current: 3.000000, Max: 3.000000

On the consumer side (python) the doubles appear to have been corrupted

qpid: Call Result: GetLimits  0 (OK) {'Limits': {u'a': {u'CURRENT': 1.0434666440167127e-320, u'MAX': 1.0434666440167127e-320}, u'c': {u'CURRENT': 1.0434666440167127e-320, u'MAX': 1.0434666440167127e-320}, u'b': {u'CURRENT': 1.0434666440167127e-320, u'MAX': 1.0434666440167127e-320}}}

Comment 1 Gordon Sim 2008-10-24 11:38:47 UTC
Fixed in r707604. Also added test: qpid/cpp/src/tests/run_header_test. This involves a c++ client sending a message with a float and a double in the header (header_test.cpp) and a python client reading that message and verifying the values of those two headers (header_test.py).

Ideally want to expand this to be bi-directional and to cover a wider range of types.

Comment 2 Frantisek Reznicek 2008-11-11 17:06:40 UTC
RHTS test qpid_test_fieldtable_encoding_issue_bz468026 shows that double value is now correctly handled. 
There is apparently problem with int64_t type which is going to be filled as separate problem.
->VERIFIED