[
https://issues.apache.org/jira/browse/AMQ-9855?focusedWorklogId=1005445&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1005445
]
ASF GitHub Bot logged work on AMQ-9855:
---------------------------------------
Author: ASF GitHub Bot
Created on: 16/Feb/26 19:25
Start Date: 16/Feb/26 19:25
Worklog Time Spent: 10m
Work Description: tabish121 commented on PR #1659:
URL: https://github.com/apache/activemq/pull/1659#issuecomment-3910213938
> @tabish121 - I know you worked on some of the transport stuff back in the
day, do you have any thoughts on this issue?
The ActiveMQ Openwire message commands are not written with concurrent
access in mind so if that is going on then you will definitely run into
trouble. There are various options in the broker and client that might come
into play here and trigger this if messages are being sent via VM Transports
and are being accessed by more than one thread. The safest course in any client
code that operates on a message outside the thread it was received on it to
copy it as the copy is a none mutating call that should allow another thread to
perform get / set operations safely.
The plain JMS consumer reads a message from the VM transport bit is safe
because every consumer gets its own copy of the message sourced from the
version that the VM transport was handed. Now if your consumer code takes that
copy of the message and send it off into more than one thread for say logging
and also a send you could see this as something concurrently reading the
message while another thread is trying to put it back through a producer could
see the state where the content and the text (or Map if using a MapMessage etc)
are both null or they might not as none of those fields is volatile.
TLDR: When in doubt copy first.
Issue Time Tracking
-------------------
Worklog Id: (was: 1005445)
Time Spent: 6h 20m (was: 6h 10m)
> 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: 6h 20m
> 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
