Bug 696919 - Message sent by python producer can't be read with java consumer
Summary: Message sent by python producer can't be read with java consumer
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: python-qpid
Version: Development
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: 3.0
: ---
Assignee: Ernie
QA Contact: mick
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-15 10:03 UTC by Petr Matousek
Modified: 2014-09-24 15:02 UTC (History)
6 users (show)

Fixed In Version: python-qpid-0.22-3.el6, python-qpid-0.22-2.el5
Doc Type: Bug Fix
Doc Text:
It was discovered that the python spout utility was defaulting the message content type to `application/octet-stream` when text content was supplied. This caused a text message generated with the python spout utility to be unreadable by the Java client. The fix sets the content type to `text/plain` in the python client, which allows the Java client to read a text message produced by the python spout utility.
Clone Of:
Environment:
Last Closed: 2014-09-24 15:02:25 UTC
Target Upstream Version:


Attachments (Terms of Use)
Default to text/plain for content_type when no message entries are supplied (937 bytes, patch)
2013-04-01 19:01 UTC, Ernie
no flags Details | Diff
Default to text/plain for content_type when no message entries are supplied (949 bytes, patch)
2013-04-19 16:41 UTC, Ernie
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Apache JIRA QPID-4772 0 None None None Never
Red Hat Product Errata RHEA-2014:1296 0 normal SHIPPED_LIVE Red Hat Enterprise MRG Messaging 3.0 Release 2014-09-24 19:00:06 UTC

Description Petr Matousek 2011-04-15 10:03:37 UTC
Description of problem:
I'm getting following exception while receiving messages sent by python client with java client:
Exception occurred: java.lang.ClassCastException: org.apache.qpid.client.message.JMSBytesMessage cannot be cast to javax.jms.TextMessage

The exception is invoked by getText() method call on received message sent by python client. Note that receiving messages sent by java client works well.

Version-Release number of selected component (if applicable):
python-qpid-0.10-1.el5
qpid-java-example-0.10-2.el5
qpid-java-client-0.10-2.el5
qpid-java-common-0.10-2.el5

How reproducible:
100%

Steps to Reproduce:
The issue can be easily reproduced using one of the following scenarios:
(A):
1. comment following line in Hello.java example
     messageProducer.send(message);
   (Now the consumer will wait until message arrives on 'amq.topic' exchange)
2. compile and execute Hello.java
3. In second CLI send a meessage to 'amq.topic' using python client (spout)

(B)
1. Download java receiver attached to BZ674005
     https://bugzilla.redhat.com/attachment.cgi?id=476159
2. Declare queue 'direct'
3. run the downloaded receiver
4. In second CLI send a message using python client to queue 'direct'

please see Additional info for terminal transcripts 
  
Actual results:
Exception invoked on java receiver while consuming messages sent by python client.

Expected results:
No exception, java consumer successfully receives messages sent by python producer.

Additional info:

CLI TRANSCRIPTS:

reproduction scenario A:

CLI1 transcript:

# pwd
/usr/share/doc/qpid-java-0.10/examples
# sed -i 's/messageProducer\.send/\/\/ messageProducer\.send/' org/apache/qpid/example/Hello.java
# ./run_example.sh org.apache.qpid.example.Hello
java.lang.ClassCastException: org.apache.qpid.client.message.JMSBytesMessage cannot be cast to javax.jms.TextMessage
	at org.apache.qpid.example.Hello.runTest(Hello.java:63)
	at org.apache.qpid.example.Hello.main(Hello.java:40)

CLI2 transcript:

# /usr/share/doc/python-qpid-0.10/examples/api/spout amq.topic "test_msg"
Message(properties={'spout-id': '8b0391da-dbc1-7249-948a-65603a0fc58b:0'}, content='test_msg')

===
reproduction scenario B:
 
CLI1 (java consumer):

# service qpidd restart
Stopping Qpid AMQP daemon:                                 [  OK  ]
Starting Qpid AMQP daemon:                                 [  OK  ]
# qpid-config add queue direct
# javac -cp $QPID_CLASSPATH P2PReceiver.java
# java -cp $QPID_CLASSPATH P2PReceiver
Reading message: Hello
Exception occurred: java.lang.ClassCastException: org.apache.qpid.client.message.JMSBytesMessage cannot be cast to javax.jms.TextMessage
java.lang.ClassCastException: org.apache.qpid.client.message.JMSBytesMessage cannot be cast to javax.jms.TextMessage
	at P2PReceiver.main(P2PReceiver.java:43)

CLI2 (sending messages using java and python client): 

# pwd
/usr/share/doc/qpid-java-0.10/examples
# ./run_example.sh org.apache.qpid.example.Spout -c 5 --content 'Hello' 'direct'
{content=Hello, c=5}
(org.apache.qpid.client.AMQConnection).

------------- Msg -------------
Body:
Hello
JMS Correlation ID: null
JMS timestamp: 1302790228498
JMS expiration: 0
JMS priority: 4
JMS delivery mode: 2
JMS reply to: null
JMS Redelivered: false
JMS Destination: 'direct'/None; None
JMS Type: null
JMS MessageID: ID:b46333ea-6be3-36af-8ff4-cb6e3812cfc9
JMS Content-Type: text/plain
AMQ message number: -1
Properties:<NONE>
-------------------------------

# cd /usr/share/doc/python-qpid-0.10/examples/api
# ./spout direct "Hello"
Message(properties={'spout-id': '884ff25e-5070-2a4f-844b-5819596ff3d7:0'}, content='Hello')

Comment 2 Rajith Attapattu 2011-04-21 18:16:47 UTC
From the java clients perspective, if the content type is not set it will default to BytesMessage.
For a message to be treated as text message the content type needs to be "text/plain".

I believe the outcome of the discussion that happened during the meeting today was to fix the spout utility in python to treat a text as unicode to allow the content type to be set as "text/plain".

I changed the component to python client as I didn't find an appropriate category for examples.

I also changed the priority and severity of the issue to 'low'.

Comment 3 Justin Ross 2013-02-22 13:16:55 UTC
Ernie, please assess.

Comment 4 Ernie 2013-03-04 18:50:51 UTC
I agree with comment 2, this appears to be a result of the java apps casting the message as a TextMessage. Since the python client is not setting the content_type, it is defaulting to application/octet-stream.

This can be verified by running the java example Drain:
------------- Msg -------------
Body:
"text"
JMS Correlation ID: null
JMS timestamp: 0
JMS expiration: 0
JMS priority: 4
JMS delivery mode: 2
JMS reply to: null
JMS Redelivered: false
JMS Destination: 'q'/None; None
JMS Type: null
JMS MessageID: null
JMS Content-Type: application/octet-stream
AMQ message number: 2
Properties:
	spout-id = 89037491-bf0a-47fc-ade5-4d76cdea6ca1:0

As evidenced above, the java apps can read the python message, they just can't assume the message is a TextMessage.

To avoid confusion, the python spout should explicitly set the content type to text/plain when no message map entries are supplied. 

As far as I can tell, this won't break any tests. It should be an easy/low risk change.

Comment 5 Ernie 2013-04-01 19:01:07 UTC
Created attachment 730384 [details]
Default to text/plain for content_type when no message entries are supplied

If message entries are supplied the content type is determined to be amqp/map. Otherwise the content_type was not specified.

For compatibility with non-python clients, the content_type is now explicitly set to text/plain for non-map messages.

Comment 6 Justin Ross 2013-04-18 14:13:21 UTC
114	    if content_type:
115	        msg.content_type = content_type

That should be a stricter check, "if content_type is None:"

Justin

Comment 7 Justin Ross 2013-04-18 14:14:05 UTC
Er, is *not None*!

Comment 8 Ernie 2013-04-19 16:41:25 UTC
Created attachment 737697 [details]
Default to text/plain for content_type when no message entries are supplied

Adds recommended 'not None'

Comment 9 Justin Ross 2013-04-23 21:18:25 UTC
-> POST

http://svn.apache.org/viewvc?view=revision&revision=1471146

Comment 10 mick 2013-07-24 17:29:42 UTC
bug observed on latest-stable packages, i.e.

    qpid-cpp-server-0.18-14.el6.x86_64

on RHEL 6.4 x86_64




fix observed on latest-and-greatest packages, i.e.

    qpid-cpp-server-0.22-7.el6.x86_64

on RHEL 6.4 x { x86_64 , i686 }



--> VERIFIED

Comment 13 errata-xmlrpc 2014-09-24 15:02:25 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2014-1296.html


Note You need to log in before you can comment on or make changes to this bug.