Robbie Gemmell updated PROTON-624:

    Fix Version/s: 0.8

> 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
>             Fix For: 0.8
>         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

Reply via email to