[
https://issues.apache.org/jira/browse/AMQ-9855?focusedWorklogId=1004974&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1004974
]
ASF GitHub Bot logged work on AMQ-9855:
---------------------------------------
Author: ASF GitHub Bot
Created on: 13/Feb/26 00:57
Start Date: 13/Feb/26 00:57
Worklog Time Spent: 10m
Work Description: cshannon commented on PR #1659:
URL: https://github.com/apache/activemq/pull/1659#issuecomment-3894219649
> Looks good. Synchronized is good enough and it's a perf killer only on vm
transport. Other transports would marshall/unmarshall and would use a different
instance. On vm, it creates contentions but that's way better than messing up
with the data. Using RentrantReadWriteLock would not improve the things because
all methods basically mutate under the cover.
Agreed, synchronized here is fine to use and as you pointed out we don't
gain anything from a ReadWrite lock as we need a write lock for basically all
methods. I wasn't around for the original implementation of classes but it
looked like the goal was to avoid synchronization as messages were meant to be
copied if used across threads. Unfortunately that pattern breaks with the VM
transport as we see due to the nature of dispatching to multiple consumers. I
don't think we see this issue with network bridges because there is only one
consumer for the VM transports in bridges (the broker itself).
The performance impact for single threaded applications using synchronized
that have no contention is pretty negligible and even with contention as we can
see correctness is more important. I'd rather the application take a couple
extra ms to dispatch all the copies of the message than to receive a null body.
I was looking more at
[AMQ-5857](https://issues.apache.org/jira/browse/AMQ-5857) and the discussion
to try and remember why we didn't add synchronized back then when trying to
clear memory to avoid storing the data twice and OOM errors and i assume we
just didn't have good enough tests to show the real issue. Plus, it was like 10
years ago so I was now to ActiveMQ :)
I haven't had time to fully review this yet but will either tomorrow or
Monday and will post more feedback.
Issue Time Tracking
-------------------
Worklog Id: (was: 1004974)
Time Spent: 4h 20m (was: 4h 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: 4h 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
