[jira] [Comment Edited] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check

["Christopher L. Shannon (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMQ-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228649#comment-15228649 ] 

Christopher L. Shannon edited comment on AMQ-6142 at 4/6/16 5:02 PM:
---------------------------------------------------------------------

[~gtully], 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.  


was (Author: christopher.l.shannon):
[~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)