You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "R@ADU (Jira)" <ji...@apache.org> on 2021/11/26 10:49:00 UTC

[jira] [Created] (AMQ-8417) ActiveMQBytesMessage - unable to read content after property is set

R@ADU created AMQ-8417:
--------------------------

             Summary: ActiveMQBytesMessage - unable to read content after property is set
                 Key: AMQ-8417
                 URL: https://issues.apache.org/jira/browse/AMQ-8417
             Project: ActiveMQ
          Issue Type: Bug
          Components: JMS client
    Affects Versions: 5.16.3
            Reporter: R@ADU
         Attachments: image-2021-11-26-12-34-28-328.png, image-2021-11-26-12-37-08-865.png, image-2021-11-26-12-42-33-028.png, image-2021-11-26-12-45-32-500.png

This issue was discovered, when using spring boot 2.5.7 and spring cloud 2020.0.4 (brave 5.13.2, and ActiveMQ Client 5.16.3)!
When sleuth is enabled, brave instrumentation jms edits the jms message, by removing properties related to sleuth, then jms message is consumed further (i.e. content is read).
The issue is when jms message is of type ActiveMQBytesMessage.
Having a closer look at how ActiveMQBytesMessage was implemented, I came to the conclusion that there is something wrong. However I do not know exactly if this is true, that's why I opened a bug for brave instrumentation jms as well. Please check for more details here: [https://github.com/openzipkin/brave/issues/1310] ;

---

*Steps:*
 # jms message, of type ActiveMQBytesMessage is received;
 # set a property on that message - use ActiveMQBytesMessage#setObjectProperty method;
 # try to read the content - use ActiveMQBytesMessage#read* method.
 # analyze the result...

*Expected:*
The content is read...

*Actual:*
no content is read... 

For more details check: [https://github.com/openzipkin/brave/issues/1310]


h2. Things to consider


When ActiveMQBytesMessage#setObjectProperty method is called
!image-2021-11-26-12-34-28-328.png!
the `initializeWritingNoCheck()` method moves the `content` to `dataOut`/`bytesOut`.
As a result, `content` will be `null` and `dataOut`/`bytesOut` will contain the bytes moved from `content`. Note `dataIn` remains `null`.
!image-2021-11-26-12-37-08-865.png!

When `ActiveMQBytesMessage#read*` method is called, for example readByte()
!image-2021-11-26-12-42-33-028.png!
the `initializeReading()` will try to prepare the `dataIn` for reading, based on the `content`... but the `content` is `null` (here is the problem actually)
!image-2021-11-26-12-45-32-500.png!
as a result, the `dataIn` is initialized with an empty sequence of bytes (i.e. empty input stream).
As a result, calling dataIn.read* method (in our example it will be dataIn.readByte()) will end in unexpected result (EOF or -1)...



--
This message was sent by Atlassian Jira
(v8.20.1#820001)