MessagingMessageListenerAdapter provides a BytesMessage that has already been read [SPR-13769]

[spring-projects-issues]

Tomoyuki Ikeya opened SPR-13769 and commented

@JmsListener does not work correctly when using ByteMessage.
I tried it with ActiveMQ Artimes and got a following result.

• When receiving ByteMessage, the method annotated was called.
• But I got empty bytes through ByteMessage.readBytes().
• I got correct result when using TextMessage, of course.

I will request a reproducing code in github.

---

Affects: 4.1.8, 4.2.3

Reference URL: https://github.com/spring-projects/spring-framework-issues/tree/master/SPR-13769

Issue Links:

• Lazy GenericMessage payload extraction for JMS endpoints [SPR-13777] #18351 Lazy GenericMessage payload extraction for JMS endpoints

Referenced from: commits 8346eed, e4faaa3

Backported to: 4.1.9

0 votes, 5 watchers

[spring-projects-issues]

Stéphane Nicoll commented

The problem is that we read the BytesMessage content already so when you do it in your own code, the buffer is not reset. Is there any reason you're doing this? You could inject a Message<byte[]> or the a byte[] parameter directly in your method.

Juergen Hoeller I wondered if we should/could call reset ourselves. Our own code is at risk right now if "something" reads the BytesMessage before we do. There are 3 places in the framework that are potentially affected.

[spring-projects-issues]

Juergen Hoeller commented

Good point, we should make sure that the BytesMessage is in consistent state there. I'm not sure whether reset() is a reliable operation though; can it fail in certain cases?

Juergen

[spring-projects-issues]

Stéphane Nicoll commented

I don't think so, the javadoc of BytesMessage is even mentioning it explicitly

When the message is first created, and when clearBody is called, the body of the message is in write-only mode. After the first call to reset has been made, the message body is in read-only mode. When a BytesMessage is sent asynchronously, the provider must call reset on the BytesMessage passed to the CompletionListener. This means that the CompletionListener can read the message body without needing to call reset. After a message has been sent, the client that sent it can retain and modify it without affecting the message that has been sent. The same message object can be sent multiple times. When a message has been received, the provider has called reset so that the message body is in read-only mode for the client.

I wonder if we should call it before, after, both or not at all. Certainly not something to do in a bugfix release though. Maybe some specific code in MessagingMessageListenerAdapter for now? (that's the only thing that actually touches the javax.jms.Message before passing it to the user AFAIK).

[spring-projects-issues]

Stéphane Nicoll commented

This was fixed in 8346eeda and about to be backported to 4.1 as well.

[spring-projects-issues]

Tomoyuki Ikeya commented

Thanks for your quick fix. It looks working as expected with ByteMessage.

[spring-projects-issues]

Stéphane Nicoll commented

Tomoyuki Ikeya your report is very valuable and I am happy we fixed this bug but I'd like to understand why you need to inject the javax.jms.BytesMessage in your code. Is there something we can improve so that you don't have to do that?