Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 902387

Summary: Qpid java client receives string as byte[] not as String when sent by a C++ qpid client (std::string in a list message)
Product: Red Hat Enterprise MRG Reporter: Frantisek Reznicek <freznice>
Component: qpid-javaAssignee: Rajith Attapattu <rattapat+nobody>
Status: CLOSED NOTABUG QA Contact: MRG Quality Engineering <mrgqe-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: DevelopmentCC: esammons, jross
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-07 16:26:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Reproducer none

Description Frantisek Reznicek 2013-01-21 14:45:20 UTC 
Description of problem:

C++ qpid client sending string in a list message is received by java client as byte[] not as String.

Going through bug 805881 I found that list messages can be send and received by all supported clients (c++, python, java).

When sending string value in list message from c++ to java client every string value is received and typed to byte[].
When sending in the same scenario from python or java client, reception by java client retypes string into String object/type.

I believe even in case c++ -> java java should receive std::string as java String and not as byte[].

Seen on every supported platform.

Version-Release number of selected component (if applicable):
  python-qpid-0.18-4.el5
  python-qpid-qmf-0.18-13.el5
  qpid-cpp-client-0.18-13.el5
  qpid-cpp-client-devel-0.18-13.el5
  qpid-cpp-client-devel-docs-0.18-13.el5
  qpid-cpp-client-rdma-0.18-13.el5
  qpid-cpp-client-ssl-0.18-13.el5
  qpid-cpp-mrg-debuginfo-0.18-13.el5
  qpid-cpp-server-0.18-13.el5
  qpid-cpp-server-cluster-0.18-13.el5
  qpid-cpp-server-devel-0.18-13.el5
  qpid-cpp-server-rdma-0.18-13.el5
  qpid-cpp-server-ssl-0.18-13.el5
  qpid-cpp-server-store-0.18-13.el5
  qpid-cpp-server-xml-0.18-13.el5
  qpid-java-client-0.18-6.el5
  qpid-java-common-0.18-6.el5
  qpid-java-example-0.18-6.el5
  qpid-jca-0.18-6.el5
  qpid-jca-xarecovery-0.18-6.el5
  qpid-jca-zip-0.18-6.el5
  qpid-qmf-0.18-13.el5
  qpid-qmf-debuginfo-0.18-13.el5
  qpid-qmf-devel-0.18-13.el5
  qpid-tests-0.18-2.el5
  qpid-tools-0.18-7.el5
  rh-qpid-cpp-tests-0.18-13.el5
  ruby-qpid-qmf-0.18-13.el5


How reproducible:
100%

Steps to Reproduce:
1. `./runtest.sh | grep 'as '`
  
Actual results:
String in list message is received as byte[] (from c++) or as String (python, java)

Expected results:
String in list message should be received as String regardless of sending client.

Additional info (transcript, el5i):
  Core tests:
  Broker Summary:
    uptime  cluster       connections  sessions  exchanges  queues
    ================================================================
    11s     <standalone>  1            1         8          1
  
  run ./list_tx.sh(0) -> ./list_rx.sh(0) [0/0]
  [ 1, 2.0, 3 [(as String)] ]
  [1, 2.0, '3' ]
  run ./list_tx.sh(1) -> ./list_rx.sh(0) [2/0]
  [ 1, 2.0, 3 [(as String)] ]
  [1, 2.0, '3' ]
  run ./list_tx(0) -> ./list_rx.sh(0) [4/0]
  [1, 2, 3]
  [ 1, 2.0, 3 [(as byte[])] ]
  run ./list_tx(1) -> ./list_rx.sh(0) [6/0]
  [1, 2, 3]
  [ 1, 2.0, 3 [(as byte[])] ]
  run ./list_tx.py(0) -> ./list_rx.sh(0) [8/0]
  [1, 2.0, '3']
  [ 1, 2.0, 3 [(as String)] ]
  run ./list_tx.py(1) -> ./list_rx.sh(0) [10/0]
  [1, 2.0, '3']
  [ 1, 2.0, 3 [(as String)] ]
  run ./list_tx.sh(0) -> ./list_rx.sh(1) [12/0]
  [ 1, 2.0, 3 [(as String)] ]
  [1, 2.0, '3' ]
  run ./list_tx.sh(1) -> ./list_rx.sh(1) [14/0]
  [ 1, 2.0, 3 [(as String)] ]
  [1, 2.0, '3' ]
  run ./list_tx(0) -> ./list_rx.sh(1) [16/0]
  [1, 2, 3]
  [ 1, 2.0, 3 [(as byte[])] ]
  run ./list_tx(1) -> ./list_rx.sh(1) [18/0]
  [1, 2, 3]
  [ 1, 2.0, 3 [(as byte[])] ]
  run ./list_tx.py(0) -> ./list_rx.sh(1) [20/0]
  [1, 2.0, '3']
  [ 1, 2.0, 3 [(as String)] ]
  run ./list_tx.py(1) -> ./list_rx.sh(1) [22/0]
  [1, 2.0, '3']
  [ 1, 2.0, 3 [(as String)] ]
  run ./list_tx.sh(0) -> ./list_rx.sh(2) [24/0]
  [ 1 (as Long), 2.0, 3 (as String) ]
  [1, 2.0, '3' ]
  run ./list_tx.sh(1) -> ./list_rx.sh(2) [26/0]
  [ 1 (as Long), 2.0, 3 (as String) ]
  [1, 2.0, '3' ]
  run ./list_tx(0) -> ./list_rx.sh(2) [28/0]
  [1, 2, 3]
  [ 1 (as Long), 2.0, 3 (as byte[]) ]
  run ./list_tx(1) -> ./list_rx.sh(2) [30/0]
  [1, 2, 3]
  [ 1 (as Long), 2.0, 3 (as byte[]) ]
  run ./list_tx.py(0) -> ./list_rx.sh(2) [32/0]
  [1, 2.0, '3']
  [ 1 (as Long), 2.0, 3 (as String) ]
  run ./list_tx.py(1) -> ./list_rx.sh(2) [34/0]
  [1, 2.0, '3']
  [ 1 (as Long), 2.0, 3 (as String) ]
  run ./list_tx.sh(0) -> ./list_rx(0) [36/0]
  [1, 2, 3]
  [1, 2.0, '3' ]
  run ./list_tx.sh(1) -> ./list_rx(0) [38/0]
  [1, 2, 3]
  [1, 2.0, '3' ]
  run ./list_tx(0) -> ./list_rx(0) [40/0]
  [1, 2, 3]
  [1, 2, 3]
  run ./list_tx(1) -> ./list_rx(0) [42/0]
  [1, 2, 3]
  [1, 2, 3]
  run ./list_tx.py(0) -> ./list_rx(0) [44/0]
  [1, 2, 3]
  [1, 2.0, '3']
  run ./list_tx.py(1) -> ./list_rx(0) [46/0]
  [1, 2, 3]
  [1, 2.0, '3']
  run ./list_tx.sh(0) -> ./list_rx(1) [48/0]
  [1, 2, 3]
  [1, 2.0, '3' ]
  run ./list_tx.sh(1) -> ./list_rx(1) [50/0]
  [1, 2, 3]
  [1, 2.0, '3' ]
  run ./list_tx(0) -> ./list_rx(1) [52/0]
  [1, 2, 3]
  [1, 2, 3]
  run ./list_tx(1) -> ./list_rx(1) [54/0]
  [1, 2, 3]
  [1, 2, 3]
  run ./list_tx.py(0) -> ./list_rx(1) [56/0]
  [1, 2, 3]
  [1, 2.0, '3']
  run ./list_tx.py(1) -> ./list_rx(1) [58/0]
  [1, 2, 3]
  [1, 2.0, '3']
  run ./list_tx.sh(0) -> ./list_rx(2) [60/0]
  [1, 2, 3]
  [1, 2.0, '3' ]
  run ./list_tx.sh(1) -> ./list_rx(2) [62/0]
  [1, 2, 3]
  [1, 2.0, '3' ]
  run ./list_tx(0) -> ./list_rx(2) [64/0]
  [1, 2, 3]
  [1, 2, 3]
  run ./list_tx(1) -> ./list_rx(2) [66/0]
  [1, 2, 3]
  [1, 2, 3]
  run ./list_tx.py(0) -> ./list_rx(2) [68/0]
  [1, 2, 3]
  [1, 2.0, '3']
  run ./list_tx.py(1) -> ./list_rx(2) [70/0]
  [1, 2, 3]
  [1, 2.0, '3']
  run ./list_tx.sh(0) -> ./list_rx.py(0) [72/0]
  [1L, 2.0, u'3']
  [1, 2.0, '3' ]
  run ./list_tx.sh(1) -> ./list_rx.py(0) [74/0]
  [1L, 2.0, u'3']
  [1, 2.0, '3' ]
  run ./list_tx(0) -> ./list_rx.py(0) [76/0]
  [1, 2, 3]
  [1L, 2.0, '3']
  run ./list_tx(1) -> ./list_rx.py(0) [78/0]
  [1, 2, 3]
  [1L, 2.0, '3']
  run ./list_tx.py(0) -> ./list_rx.py(0) [80/0]
  [1L, 2.0, u'3']
  [1, 2.0, '3']
  run ./list_tx.py(1) -> ./list_rx.py(0) [82/0]
  [1L, 2.0, u'3']
  [1, 2.0, '3']
  run ./list_tx.sh(0) -> ./list_rx.py(1) [84/0]
  [1L, 2.0, u'3']
  [1, 2.0, '3' ]
  run ./list_tx.sh(1) -> ./list_rx.py(1) [86/0]
  [1L, 2.0, u'3']
  [1, 2.0, '3' ]
  run ./list_tx(0) -> ./list_rx.py(1) [88/0]
  [1, 2, 3]
  [1L, 2.0, '3']
  run ./list_tx(1) -> ./list_rx.py(1) [90/0]
  [1, 2, 3]
  [1L, 2.0, '3']
  run ./list_tx.py(0) -> ./list_rx.py(1) [92/0]
  [1L, 2.0, u'3']
  [1, 2.0, '3']
  run ./list_tx.py(1) -> ./list_rx.py(1) [94/0]
  [1L, 2.0, u'3']
  [1, 2.0, '3']
  run ./list_tx.sh(0) -> ./list_rx.py(2) [96/0]
  [1L, 2.0, u'3']
  [1, 2.0, '3' ]
  run ./list_tx.sh(1) -> ./list_rx.py(2) [98/0]
  [1L, 2.0, u'3']
  [1, 2.0, '3' ]
  run ./list_tx(0) -> ./list_rx.py(2) [100/0]
  [1, 2, 3]
  [1L, 2.0, '3']
  run ./list_tx(1) -> ./list_rx.py(2) [102/0]
  [1, 2, 3]
  [1L, 2.0, '3']
  run ./list_tx.py(0) -> ./list_rx.py(2) [104/0]
  [1L, 2.0, u'3']
  [1, 2.0, '3']
  run ./list_tx.py(1) -> ./list_rx.py(2) [106/0]
  [1L, 2.0, u'3']
  [1, 2.0, '3']
  Final broker[s] test: [108/0]4060 done
  Stopping brokers... [108/0]
  .
  qpidd: no process killed
  Checking core files... [108/0]
  ===---=== SUMMARY ===---===
  dur:173, tst_cnt:109, err_cnt:0
Comment 1 Frantisek Reznicek 2013-01-21 14:53:24 UTC 
Created attachment 684352 [details]
Reproducer

Usage:
  service qpidd stop
  ./runtest.sh
Comment 2 Rajith Attapattu 2013-10-07 16:26:34 UTC 
This is not a bug. The application needs to explicitly set the encoding type type properly (Ex utf-8).
Using std:string will cause the c++ client to just send it without any encoding information.

Currently Darryl is involved in finding a better solution for this.

There is nothing wrong with the java client.

Closing this bug as it's not a bug with the java client.