Activemq loses Stomp text message body on topic
-----------------------------------------------
Key: AMQ-2871
URL: https://issues.apache.org/activemq/browse/AMQ-2871
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.3.2
Environment: Debian linux 64bit, with:
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-1)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
ActiveMQ 5.3.2
Reporter: Arjen van der Meijden
I have a fairly simple set-up with a single Activemq.
On that AMQ we have a few queue's and topics, where the topics are filled using
PHP producers with Stomp and four Java subscribers with the normal openwire
protocol (via a Spring jms listener container). The PHP producers are created
on demand and send a single, tiny text message when some data needs to be
adjusted in the Java subscribers.
The problem is that all four consumers sometimes receive a message without such
a text body. Using tcpdump I deciphered that the incoming Stomp-message
actually did have a body, so the senders work correctly. Again using tcpdump I
noticed the messages on the openwire channel are sometimes empty, so the
problem seems to be with the ActiveMQ server part.
Not all messages fail, but its way too common (a rough estimate would be one in
ten or so). I also didn't see any message empty when using a OpenWire-producer.
My configuration is rather trivial, its the default config without systemusage
and destinationpolicy. With the stomp and openwire transporters like so:
<transportConnector name="stomp"
uri="stomp://0.0.0.0:61613?transport.closeAsync=false"/>
When logging the messages in the subscribers, it looks like this for a correct
one:
ActiveMQTextMessage {commandId = 3, responseRequired = false, messageId =
ID:argus-38958-1279890714168-2:66257231:-1:1:1, originalDestination = null,
originalTransactionId = null, producerId =
ID:argus-38958-1279890714168-2:66257231:-1:1, destination =
topic://pw_cache_products, transactionId = null, expiration = 0, timestamp =
1281801902987, arrival = 0, brokerInTime = 1281801902987, brokerOutTime =
1281801902988, correlationId = null, replyTo = null, persistent = false, type =
null, priority = 0, groupID = null, groupSequence = 0, targetConsumerId = null,
compressed = false, userID = null, content = null, marshalledProperties = null,
dataStructure = null, redeliveryCounter = 0, size = 0, properties = null,
readOnlyProperties = true, readOnlyBody = true, droppable = false, text = views
0}
And like this for an incorrect one:
ActiveMQTextMessage {commandId = 3, responseRequired = false, messageId =
ID:argus-38958-1279890714168-2:66384399:-1:1:1, originalDestination = null,
originalTransactionId = null, producerId =
ID:argus-38958-1279890714168-2:66384399:-1:1, destination =
topic://pw_cache_products, transactionId = null, expiration = 0, timestamp =
1281805503252, arrival = 0, brokerInTime = 1281805503252, brokerOutTime =
1281805503252, correlationId = null, replyTo = null, persistent = false, type =
null, priority = 0, groupID = null, groupSequence = 0, targetConsumerId = null,
compressed = false, userID = null, content = null, marshalledProperties = null,
dataStructure = null, redeliveryCounter = 0, size = 0, properties = null,
readOnlyProperties = true, readOnlyBody = true, droppable = false, text = null}
I.e. text = null vs text = views 0
I couldn't reproduce this on another system so far. And my production ActiveMQ
that displays this behaviour gets way to much traffic to put in in
debug-logging-mode (and I doubt that will offer much insight anyway?). I can
reproduce it on a newly created topic on the same activemq with only one
consumer and producer, but not on a separate activemq. Whether that is because
it has less load or whatever I don't know, the original activemq that does
exhibit this behaviour has been upgraded and restarted several times since we
first started noticing the problems that led to this discovery.
My consumers and producers are about the most trivial variants you can think
off, but the other producers and consumers obviously aren't.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
