-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Message body does not display in the ActiveMQ web ui #19
Comments
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 |
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. |
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. |
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 |
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! |
Interesting, thanks for the research! I'll have to start testing that out. If nothing else, I can at least use it for dev. |
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.
The text was updated successfully, but these errors were encountered: