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

Christopher L. Shannon edited comment on AMQ-6142 at 4/8/16 11:14 AM:
----------------------------------------------------------------------

Yep agreed, lets roll back the sync I added.  I think the Jira reported for 
AMQ-5857 was about client side and not the broker side (since 
reduceMemoryFootprint exists to clear the duplicate state, at least for 
queues).  I would say we either need to roll that commit back as well or maybe 
figure out a way so that the client can clear out the state but the broker 
won't clear it out until it is safe to do so.


was (Author: christopher.l.shannon):
Yep agreed, lets roll back the sync I added.  I think the Jira reported for 
AMQ-5857 was about client side and not the broker side (since 
reduceMemoryFootprint exists to clear the duplicate state, at least for 
queues).  I would say we either need to roll that back that commit as well or 
maybe figure out a way so that the client can clear out the state but the 
broker won't clear it out until it is safe to do so.

> 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)

Reply via email to