[
https://issues.apache.org/jira/browse/AMQ-6708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18055670#comment-18055670
]
JJ edited comment on AMQ-6708 at 1/31/26 7:08 PM:
--------------------------------------------------
Hi [~tolk] I've apparently found the same issue but can offer a bit more in the
way of a simple setup to try and investigate;
I see this problem on a number of test instances using 6.1.x & 6.2 (Java 21LTS)
but not on an old 5.17.x broker.
Brokers all use camel LTS. The broker connections to an upstream server and
subscribes to a topic. That topic is then bridged to the local server.
<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 openwire 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
I've not been able to test any older than ruby 3.1 builds due to potential
downgrade issues.
Sadly I don't know when the issue first appeared as that server the consumers
tend to consume from a processed topic (which is not experiencing any issues
either) it was only when we run our test script connecting to that server we
noticed.
I think this is server side somewhere as the same client connected to the old
server does not have these issues.
Let me know if that's helpful or you need any more info a novice can provide. I
don't always get notifications from here so will try and check back in a week
or so.
was (Author: jj-amq):
Hi [~tolk] I've apparently found the same issue but can offer a bit more in the
way of a simple setup to try and investigate;
I see this problem on a number of test instances using 6.1.x & 6.2 (Java 21LTS)
but not on an old 5.17.x broker.
Brokers all use camel LTS. The broker connections to an upstream server and
subscribes to a topic. That topic is then bridged to the local server.
<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 openwire 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
I've not been able to test any older than ruby 3.1 builds due to potential
downgrade issues.
Sadly I don't know when the issue first appeared as that server the consumers
tend to consume from a processed topic (which is not experiencing any issues
either) it was only when we run our test script connecting to that server we
noticed.
Let me know if that's helpful or you need any more info a novice can provide. I
don't always get notifications from here so will try and check back in a week
or so.
> When reading from a topic, messages will intermittently have empty body text
> ----------------------------------------------------------------------------
>
> Key: AMQ-6708
> URL: https://issues.apache.org/jira/browse/AMQ-6708
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.14.3
> Environment: CentOS 7
> Reporter: Peter Boekelheide
> Priority: Major
> Attachments: config.zip
>
>
> We've come across a problem with our brokers wherein messages consumed from a
> topic will intermittently have null/empty body text. This is regardless of
> the type of consumer we use, be it stomp or openwire. There doesn't seem to
> be any particular pattern to the null messages that we can see, and they may
> be null for one consumer but the same message would have a body for another
> consumer. While we can consistently reproduce it in the sense that we can
> connect a consumer and wait for a period of time (usually a couple of
> minutes) and the issue will occur, we can't seem to find the exact conditions
> under which the null message happens.
> I know this a relatively vague issue description, but I'm not sure what more
> you'd be looking for right now. Please comment and let me know if you'd like
> more information. This is currently a major problem for us, as it makes our
> topics unreliable.
--
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
