[
https://issues.apache.org/jira/browse/AMQ-8417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
R@DU updated AMQ-8417:
----------------------
Description:
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]
was:
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)...
*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]
> 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)
