[
https://issues.apache.org/jira/browse/AMQ-9855?focusedWorklogId=1005218&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1005218
]
ASF GitHub Bot logged work on AMQ-9855:
---------------------------------------
Author: ASF GitHub Bot
Created on: 15/Feb/26 08:57
Start Date: 15/Feb/26 08:57
Worklog Time Spent: 10m
Work Description: pradeep85841 commented on PR #1659:
URL: https://github.com/apache/activemq/pull/1659#issuecomment-3903816329
I have updated to address the feedback from @cshannon and @jeanouii. This
revision ensures total thread safety for the VM Transport "defensive copy"
logic while adhering to the project's coding standards and memory-management
goals.
Key Changes:
Full Synchronization: Per the suggestion to "go all the way," I have applied
the synchronized keyword to all state-dependent methods in ActiveMQTextMessage.
This includes getText(), setText(), getSize(), clearBody(), and
clearUnMarshalledState().
Data Integrity: In clearUnMarshalledState(), I ensured that storeContent()
is called (if bytes are missing) before the local text reference is nulled.
This prevents the "double-null" scenario where a message could lose its content
entirely during a race.
Encapsulation: Reverted the copy(ActiveMQTextMessage) helper method to
private visibility.
Stress Test Improvements: * Replaced printStackTrace with SLF4J logging.
Added proper braces {} to all conditional blocks.
Refined the concurrency logic using an ExecutorService and Future validation
to simulate high-pressure dispatching across multiple durable and non-durable
subscribers.
Optimized the test payload and iteration count to verify the fix under high
contention without triggering OutOfMemoryError on restricted heap environments.
Verification: The updated ActiveMQTextMessageStressTest confirms that even
when multiple consumers hammer getText() and clearUnMarshalledState()
concurrently on messages dispatched via the VM transport, the data remains
intact and instances remain independent.
The fix has been verified in original environment and the test suite is now
passing with a clean exit.
Issue Time Tracking
-------------------
Worklog Id: (was: 1005218)
Time Spent: 5h 10m (was: 5h)
> Intermittent null/empty body when consuming from a topic (vm:// transport)
> --------------------------------------------------------------------------
>
> Key: AMQ-9855
> URL: https://issues.apache.org/jira/browse/AMQ-9855
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP, Camel
> Affects Versions: 6.2.0, 6.1.2, 6.1.6, 6.1.7
> Reporter: JJ
> Priority: Major
> Fix For: 6.3.0
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> Also see AMQ-6708 This is very much the same issue but with more details. The
> op on that ticket hasn't been seen since 2017.
> We have a simple AMQ instance using Camel; It connects to an upstream remote
> server via OpenWire and subscribes to topics. It Bridges those topics to the
> local AMQ with some later Camel processing.
> The route looks like this:
> <route id="Route_SPLITTER">
> <from uri="remoteServer:topic:TOPIC_A?durableSubscriptionName=some.user"/>
> <choice>
> <when>
> <simple>${body} == null || ${body} == ''</simple>
> <log message="Received message with missing body:
> ${header.CamelMessageHistory}"/>
> </when>
> <otherwise>
> </otherwise>
> </choice>
>
> <to uri="localAMQ:topic:MY_TOPIC_A"/>
> <split streaming="true" >
> <method ref="Splitter" method="processMessage"/>
> <multicast>
> <to uri="direct:routeSorter"/>
> </multicast>
> </split>
> </route>
>
> Logging was added to make sure it wasn't an upstream issue (and it's not)
>
> The data being passed is formatted as arrays of JSON. The <to
> uri="localAMQ:topic:MY_TOPIC_A"/> just passes it untouched. The Splitter send
> a copy elsewhere to be filtered by an order number prefix.
> The internal Camel to AMQ connection is via the vm:// transport using
> org.apache.camel.component.activemq.ActiveMQComponent (but I have also tried
> a pooled JMS connection factory with the same results)
> When I connect a test non durable consumer from a Ruby script using STOMP, or
> NIO I see the same issue. Some messages appear to have a 0 sized body.
> I can connect an c++ open wire consumer from the same server and that
> instance gets all messages with no 0 size bodies.
> I have tried various versions of Camel and all exhibit the same results.
> It;'s also worth noting that the data sent to the splitter function reports
> no errors either.
> I have also tried some of the older STOPM GEM packages but no change. (Though
> I have found some odd connection issue when you upgrade to io-wait-0.4.0 from
> 0.3.1
>
> After much swapping things round and testing I've finally narrowed it down to
> some issue with the vm:// transport...
> I have swapped the internal Camel connection from using vm:// to tcp:// and
> for the last 24hrs have seen no client errors with 0 sized bodies.
> I don't have any way to debug this deeper but hopefully someone else will
> pick this up.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
