[jira] Commented: (STOMP-5) StompConnect.convertMessage() should call BytesMessage.reset()

> StompConnect.convertMessage() should call BytesMessage.reset()
> --------------------------------------------------------------
>
>                 Key: STOMP-5
>                 URL: http://jira.codehaus.org/browse/STOMP-5
>             Project: Stomp
>          Issue Type: Bug
>         Environment: JBoss Messaging 1.4.0CR2
>            Reporter: Julian Scheid
>            Priority: Minor
>         Attachments: stompconnect-bytesmessage-robustness.patch
>
>
> I've run into a problem with StompConnect 1.0 running on top of JBoss Messaging 1.4.0CR2.
> The JMS spec isn't really clear about this so I'm not actually sure whether it's a bug in StompConnect. Anyway, here goes:
> When a BytesMessage is redelivered (when a durable subscriber re-subscribes), I receive a message whose body has the right size but consists entirely of zero bytes (NUL bytes, not ASCII '0').
> This seems to happen because neither JBoss Messaging nor StompConnect calls BytesMessage.reset(). So when BytesMessage.getBytes() is called at redelivery, the stream pointer points to the end of the message (apparently because the stream has been read before on the first delivery) and so no bytes are read, resulting in an all-zero byte[] being passed on.
> I'll file a corresponding bug with JBoss Messaging, suggesting that they make sure that when a message is passed to MessageListener.onMessage(), BytesMessage.reset() is called.
> However, even if it's the JMS provider's responsibility to call reset() - again, the JMS spec isn't very clear in this regard -, I would think that StompConnect would benefit in terms of robustness from adding the reset() call as well just in case. It should probably also check the return value of getBytes() and make sure that the expected number of bytes could be read. Please find both changes in attached patch.