Skip to content

[6.2.x] Fix TextMessage body thread safety (#2188)#2204

Merged
cshannon merged 2 commits into
apache:activemq-6.2.xfrom
cshannon:backport-2188-6.2.x
Jul 9, 2026
Merged

[6.2.x] Fix TextMessage body thread safety (#2188)#2204
cshannon merged 2 commits into
apache:activemq-6.2.xfrom
cshannon:backport-2188-6.2.x

Conversation

@cshannon

@cshannon cshannon commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

This fixes the rare null body issues seen on the broker when using text messages by using synchronization when marshaling or unmarshaling the body into a String to prevent a race condition from causing the body to end up null. This has been optimized to use volatiles and double checked locking to avoid synchronization unless needed.

(cherry picked from commit b131c3d)

This fixes the rare null body issues seen on the broker when using text
messages by using synchronization when marshaling or unmarshaling the
body into a String to prevent a race condition from causing the body to
end up null. This has been optimized to use volatiles and double checked
locking to avoid synchronization unless needed.

(cherry picked from commit b131c3d)
Validates the fix for the race between getText(), storeContentAndClear()
and copy() on a shared ActiveMQTextMessage instance that could null the
message body: getText() decoded content into text and cleared content
while storeContentAndClear() observed the pre-clear content, skipped
re-encoding, and cleared text — losing the body permanently. Triggered on
the broker by XPath selector evaluation or JMX browse racing dispatch
marshalling, with the network bridge copy() adding a third participant.

Four tests:
- sequential control: getText/storeContentAndClear round trips preserve
  the body
- two-way race: 20k iterations of concurrent getText vs
  storeContentAndClear; no iteration may lose the body
- three-way race including copy(): both the original and the copy must
  retain a recoverable body (pre-fix this loses the original's body
  within a few thousand iterations)
- deterministic lock-discipline pin: the fix serializes the text/content
  state transitions on the message instance, so storeContentAndClear()
  must block while another thread holds the message monitor; fails
  immediately on any regression to unsynchronized transitions

Verified failing (2 of 4) against the pre-fix base and passing on this
branch.

Co-authored-by: Matt Pavlovich <mattrpav@apache.org>
(cherry picked from commit e1368d5)
@cshannon cshannon merged commit a919915 into apache:activemq-6.2.x Jul 9, 2026
3 of 4 checks passed
@cshannon cshannon deleted the backport-2188-6.2.x branch July 9, 2026 23:45
@github-project-automation github-project-automation Bot moved this from Todo to Done in Apache ActiveMQ v6.2.8 Jul 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

Development

Successfully merging this pull request may close these issues.

1 participant