[
https://issues.apache.org/jira/browse/PROTON-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reassigned PROTON-624:
-------------------------------------
Assignee: Robbie Gemmell
> Corrupted payload with redelivered messages when transformer is jms
> -------------------------------------------------------------------
>
> Key: PROTON-624
> URL: https://issues.apache.org/jira/browse/PROTON-624
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
> Affects Versions: 0.7
> Environment: ActiveMQ broker with amqp transportConnector
> transport.transformer=jms
> Reporter: Jesse Fugitt
> Assignee: Robbie Gemmell
> Labels: jms
> Attachments: bytes_message_reset.patch
>
>
> In the contrib\proton-jms module (used by ActiveMQ), the
> JMSMappingOutboundTransformer is missing a reset call needed to make sure the
> BytesMessage is readable for future calls to readBytes(). The result is that
> redelivered messages from the broker to AMQP consumers have a payload of the
> correct length but with corrupted content (really all 0's as the content).
> To reproduce, call transform() in JMSMappingOutboundTransformer with a
> BytesMessage and then call it again with the same BytesMessage object. The
> body of the second EncodedMessage will be filled with 0's instead of having
> the real payload. To reproduce with ActiveMQ, configure the amqp
> transportConnector with transport.transformer=jms and then send a message
> into the broker. Once the message is assigned to a proton receiver (without
> acking it) close the connection and start another proton connection/receiver
> so the message will be redelivered to it. The payload should contain all 0's
> instead of the real payload.
> The other outbound transformer in proton-jms (AMQPNativeOutboundTransformer)
> makes the reset call as expected so it doesn't suffer from this bug. Based
> on that class the fix appears to be a one-liner to just add m.reset() after
> m.readBytes(data).
> The component is really proton-jms rather than proton-j but that wasn't a
> choice in JIRA.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
