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

["R@DU (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AMQ-8417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

R@DU reopened AMQ-8417:
-----------------------

> 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@DU
>            Priority: Critical
>         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!
> Note the comment done above `this.content = null;`!
> 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)...
> *Solution (in my opinion)*
> Fix should be done in org.apache.activemq.command.ActiveMQBytesMessage#initializeReading() method.
> When `content` is null, then org.apache.activemq.command.ActiveMQBytesMessage#storeContent() method should be called.
> Here is the code snippet:
> {code:java}
> ByteSequence data = getContent();
> if (data == null) {
>     storeContent();
>     data = getContent(); // storeContent() will set the content... only if dataOut != null;
>     if (data == null) {
>         data = new ByteSequence(new byte[] {}, 0, 0); // don't understand why we should silently fallback to an empty byte sequence... I would opt for an exception
>     }
> } {code}
> This is just my opinion ^.
>  
> Note: I do not know who should do the fix, that's why I have created this bug, and additionally I have created a bug on the ActiveMQ client-side, in the hope to obtain a resolution ASAP... check [https://github.com/openzipkin/brave/issues/1310]



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