You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Daniel Jabbour <da...@infoex.com> on 2008/10/16 08:10:03 UTC

STOMP to ActiveMQ/JMS and message type

Team-

I recently upgraded from ActiveMQ 5.1 to ActiveMQ 5.2 broker. I am  
sending messages from a Ruby STOMP client and consuming them in a JMS  
application. Previously, the messages were coming through as  
TextMessages (with ActiveMQ 5.1). After the upgrade, I started getting  
ActiveMQBytesMessages. I noticed some list postings back in 2006 about  
this issue... but it's interesting it resurfaced after my ActiveMQ  
broker upgrade (with no code changes to my producer or consumers).

The summary of the issue as I understand it:
  * The Ruby STOMP client sends "content-length" headers.
  * Previously, it was suggested to patch the Ruby STOMP client to  
omit this header, thus forcing JMS/ActiveMQ to evaluate the message as  
a TextMessage.
  * However, the STOMP client is also sending "content-type: text/ 
plain; charset=UTF-8" in the headers.

So my question is two-fold:
  * What changes from ActiveMQ 5.1 to 5.2 that broke the STOMP  
client's ability to send TextMessages?
  * It seems silly to patch the STOMP client to omit a header to force  
the message type. Why is ActiveMQ/JMS ignoring the content-type: text/ 
plain header? Wouldn't it make more sense to evaluate that header to  
determine the message type?

Thank you very much in advance,

Daniel

--
Daniel Jabbour
Executive Vice President of Systems Architecture
Office: (646) 778-3789 x707
daniel@infoex.com
InfoExchange, Inc.


Re: STOMP to ActiveMQ/JMS and message type

Posted by Dejan Bosanac <de...@ttmsolutions.com>.
Hi Daniel,

this is how ActiveMQ Stomp implementation works. Take a look at:

http://activemq.apache.org/stomp.html#Stomp-WorkingwithJMSText/BytesMessagesandStomp

if you send a content-length header, it will be treated as byte message.
I don't see how it could be changed between 5.1 and 5.2, because it
works this way for quite a long time.

As for the content-type, protocol (http://stomp.codehaus.org/Protocol)
does not specify anything about it, so it is ignored. I'm not sure why
your client library set this value. However, we plan to support better
message transformation for Stomp 1.1 (which is already implemented in
ActiveMQ).

Take a look at the following links for more info

http://activemq.apache.org/stomp.html#Stomp-Messagetransformations
http://stomp.codehaus.org/Stomp+v1.1+Ideas#Stompv1.1Ideas-Messagetransformation


Cheers

-- 
Dejan Bosanac


http://www.ttmsolutions.com - get a free ActiveMQ user guide

ActiveMQ in Action - http://www.manning.com/snyder/
Scripting in Java - http://www.scriptinginjava.net



Daniel Jabbour wrote:
> Team-
>
> I recently upgraded from ActiveMQ 5.1 to ActiveMQ 5.2 broker. I am
> sending messages from a Ruby STOMP client and consuming them in a JMS
> application. Previously, the messages were coming through as
> TextMessages (with ActiveMQ 5.1). After the upgrade, I started getting
> ActiveMQBytesMessages. I noticed some list postings back in 2006 about
> this issue... but it's interesting it resurfaced after my ActiveMQ
> broker upgrade (with no code changes to my producer or consumers).
>
> The summary of the issue as I understand it:
>  * The Ruby STOMP client sends "content-length" headers.
>  * Previously, it was suggested to patch the Ruby STOMP client to omit
> this header, thus forcing JMS/ActiveMQ to evaluate the message as a
> TextMessage.
>  * However, the STOMP client is also sending "content-type:
> text/plain; charset=UTF-8" in the headers.
>
> So my question is two-fold:
>  * What changes from ActiveMQ 5.1 to 5.2 that broke the STOMP client's
> ability to send TextMessages?
>  * It seems silly to patch the STOMP client to omit a header to force
> the message type. Why is ActiveMQ/JMS ignoring the content-type:
> text/plain header? Wouldn't it make more sense to evaluate that header
> to determine the message type?
>
> Thank you very much in advance,
>
> Daniel
>
> -- 
> Daniel Jabbour
> Executive Vice President of Systems Architecture
> Office: (646) 778-3789 x707
> daniel@infoex.com
> InfoExchange, Inc.
>
>