Message body does not display in the ActiveMQ web ui

[Patrick Sharp]

Using onstomp to send json strings to activeMQ and it seems to be working, but when I drill down into the messages on the activeMQ UI, the message body is blank.

The properties show:
content-type text/plain;charset=UTF-8

Is this an encoding issue?

We're using ruby hashes and applying to_json to them. It does appear that they are escaped multiple times, perhaps that could be causing a problem?

1.9.2p320 :003 > m = {hello: "world"}
=> {:hello=>"world"}
1.9.2p320 :004 > m.to_json
=> "{"hello":"world"}"
1.9.2p320 :005 > StompQueue.enqueue_command(m.to_json)
=> ""{\"hello\":\"world\"}""

enqueue_command is just a wrapper for send.

[Ian Eccles]

I've experienced the same behavior with ActiveMQ myself, even with other Ruby STOMP libraries. However, I've never had an issue with the messages being bodiless when sent to subscribers, so I'm not sure exactly what's up with the ActiveMQ web console.

As for double escaping, I'm confident that message bodies aren't being escaped unnecessarily. The OnStomp::Client#send method returns an OnStomp::Components::Frame instance, so StompQueue.enqueue_command in that example has to be doing something more than just wrapping the send method if that's a direct copy/paste. By the looks of it, I'd say String#inspect is being applied twice.

[Patrick Sharp]

I didn't think the escaping would cause an issue, but it's always better to check.

I would suspect an encoding issue, but the UI consistently claims it's UTF-8 and on the ruby side, it's always either UTF-8 or ASCII, nothing odd going on.

I can always get the message back out from the queue with no issues, but the admin would make debug a bit easier.

[Ian Eccles]

I actually do remember why ActiveMQ's web console doesn't show the messages. Prior to the STOMP 1.1 protocol, there was no standardized content-type / encoding header, and ActiveMQ effectively treated message bodies as BLOBs (I believe they were specifically cast as BytesMessage objects.) My experience with this issue was with the web console form ActiveMQ < 5.6 (when STOMP 1.1 support was added.) If you're using a newer version and still seeing this behavior, then I'd guess that internally ActiveMQ is still using a BytesMessage object to represent STOMP message frames, but I'm not certain of that.

[Ian Eccles]

After reviewing ActiveMQ's source and STOMP specific documentation, it appears that even with a STOMP 1.1 connection and a text-like "content-type" header, ActiveMQ is producing a BytesMessage. Here's the relevant documentation:

http://activemq.apache.org/stomp.html#Stomp-WorkingwithJMSText%2FBytesMessagesandStomp

Unfortunately, there's no easy way to get around it, as OnStomp will always set the 'content-length' header of a frame with a body. Attempts to override the header (e.g., by supplying {'content-type' => nil} as a third argument to Client#send) won't work because a step in the frame => string serialization process forces the content length header to be set appropriately.

[Ian Eccles]

I'm wrong about the "no easy way to get around it" comment.

If you set the 'amq-msg-type' header to 'text', ActiveMQ will produce a TextMessage instance that is readable through the web console. For example:

client.send("/queue/testing", "This is a test message", { 'amq-msg-type' => 'text' })

I've done some (very) limited testing with ActiveMQ 5.7 to confirm that this works. However, as this is ActiveMQ specific behavior and I'm not familiar enough with its internals, use it at your own risk!

[Patrick Sharp]

Interesting, thanks for the research! I'll have to start testing that out. If nothing else, I can at least use it for dev.