[
https://issues.apache.org/activemq/browse/AMQ-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62024#action_62024
]
Michael Chen commented on AMQ-2929:
-----------------------------------
Indeed adding the following line between line 88 and 89 of
ActiveMQTextMessage.java fixed the second bug and offer a temporary workaround
for the problem as a whole:
diff ActiveMQTextMessage.java patch/ActiveMQTextMessage.java
88a89
> setCompressed(false);
The first bug mentioned above needs to be fixed, i.e. the broker must not call
ActiveMQTextMessage.getText() to avoid decompressing the message when no
consumer is available when the message is enqueued.
> Compressed text message received by consumer uncompressed
> ---------------------------------------------------------
>
> Key: AMQ-2929
> URL: https://issues.apache.org/activemq/browse/AMQ-2929
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.3.2
> Environment: ActiveMQ 5.3.2 / Camel 2.2.0
> Reporter: Michael Chen
>
> I have a queue setup to send and consume compressed text messages. This is
> done via Spring setting ActiveMQConnectionFactory.useCompression to true. If
> the consumer connects to this queue before the first message is arrives,
> everything works great.
> If the messages are sent to this queue before the consumer connects, those
> early messages will cause ZipException "unknown compression method" when
> consumed by the belated consumer. Debugger shows that the
> ActiveMQTextMessage.content already contains the uncompressed text (with 4
> leading length bytes) when ActiveMQTextMessage.getText() is called.
> If I set useCompression to false, early messages are consumed with no
> problems. Please look into this.
> I notice that after ActiveMQTextMessage.getText() decompress the message, it
> does not set compressed to false. Not sure if that is the cause.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
