| Summary: | Message sent by python producer can't be read with java consumer | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Petr Matousek <pematous> | ||||||
| Component: | python-qpid | Assignee: | Ernie <eallen> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | mick <mgoulish> | ||||||
| Severity: | low | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | Development | CC: | freznice, iboverma, jross, lzhaldyb, mgoulish, rattapat+nobody | ||||||
| Target Milestone: | 3.0 | Keywords: | Patch | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| 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.
|
Story Points: | --- | ||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2014-09-24 15:02:25 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
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'. Ernie, please assess. 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. 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.
114 if content_type: 115 msg.content_type = content_type That should be a stricter check, "if content_type is None:" Justin Er, is *not None*! Created attachment 737697 [details]
Default to text/plain for content_type when no message entries are supplied
Adds recommended 'not None'
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
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 |
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')