[
https://issues.apache.org/jira/browse/AMQ-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228649#comment-15228649
]
Christopher L. Shannon commented on AMQ-6142:
---------------------------------------------
[~Gary Tully], Seems like this same issue reported in AMQ-6218 that caused me
to add synchronization has also come up before in AMQ-2966. What do you think
about rolling back the fix I added from AMQ-5857 that clears out the text field
after marshalling? That was the start of all of these issues since state is
now mutated and before it wasn't. The downside is that the data would once
again be stored twice leading to possible OOM issues, including for clients
which is why originally AMQ-5857 was submitted. So it would be nice to be able
to clear it out but not if other concurrent issues keep popping up.
Also, on a related note having to do with changing message state during
dispatch, as I was digging back through some of this stuff I was looking at the
reduceMemoryFootPrint flag and wondering if it could be applied to topics. I'm
guessing it caused issues before so it wasn't applied (maybe with concurrent
store and dispatch for topics) but it would be useful to be able to turn it on,
especially if concurrent store and dispatch is off, which is the default.
> ActiveMQBytesMessage decompress throws DataFormatException incorrect header
> check
> ---------------------------------------------------------------------------------
>
> Key: AMQ-6142
> URL: https://issues.apache.org/jira/browse/AMQ-6142
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.10.2, 5.12.1, 5.11.3, 5.13.0
> Reporter: Claudio Tagliola
> Assignee: Christopher L. Shannon
> Fix For: 5.13.1, 5.14.0
>
> Attachments: Client.java, MessageListener.java, Server.java,
> amq-6142.diff, pom.xml
>
>
> In our environment we use an embedded broker. On one topic where compression
> is enabled, the server is also listening in on the messages. From ActiveMQ
> 5.10.0 up to 5.13.0, we encounter DataFormatException: incorrect header check
> exceptions on the tcp clients due to corruption of the payload. Attached are
> a test server and client. At some point, the client will exit due to
> mentioned exception. Increase chances by running multiple clients. This
> scenario works with 5.8.0 and 5.9.1.
> If the server has multiple consumers on the same topic, they will encounter
> corruption as well, but this has other side-effects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
