activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dejan Bosanac <de...@nighttale.net>
Subject Re: Non-ASCII messages via Stomp being dropped or mangled in 5.5
Date Thu, 21 Jul 2011 09:32:45 GMT
As far as I know unicode chars are two-bytes long, so that could be a cause.
You should convert it explicitly to byte array and then send it.

Regards
-- 
Dejan Bosanac - http://twitter.com/dejanb
-----------------
The experts in open source integration and messaging - http://fusesource.com
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net


On Wed, Jul 20, 2011 at 8:08 PM, atani <jstevenson@bepress.com> wrote:

>
> Thanks, Dejan.  Fiddling with sending a "BytesMessage" results in another
> interesting error.
> When I send a plain ASCII-containing bytes message specifying a
> content-length equal
> to the length of the message body not including the terminating null byte,
> everything
> is fine.  But when I send a message that contains the byte encoded form of
> a
> unicode
> string, and a content-length equal to the length of the body in bytes but
> not
> including the terminating null byte, an exception is thrown.
>
>
> : org.apache.activemq.transport.stomp.ProtocolException: content-length
> bytes were read and there was no trailing null byte
> 2011-07-20 10:32:50,715 [2.5.9.197:56330] DEBUG ProtocolConverter
> - Exception detail
> org.apache.activemq.transport.stomp.ProtocolException: content-length bytes
> were read and there was no trailing null byte
>        at
>
> org.apache.activemq.transport.stomp.StompWireFormat.unmarshal(StompWireFormat.java:109)
>        at
>
> org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:227)
>        at
> org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:219)
>        at
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:202)
>        at java.lang.Thread.run(Thread.java:662)
>
>
> Frame 1 - OK
>
> ASCII characters sent as bytes with a content-length header equal to the
> length
> of the *body*.  The terminating null byte is replaced in my log with the
> [NUL]
> seen below so I can confirm it's presence - but the frame is sent with the
> actual
> null byte.
>
>
> SEND
> destination:/queue/jstevenson@jstevenson2.msgtest2
> content-length:59
>
> Wed Jul 20 10:32:50 2011 utf8 encoded: I'm a simple message[NUL]
>
>
> Frame 2 - Not OK
>
> Unicode characters encoded into bytes with a content-length header also
> equal to the
> length of the *body*.  A similar failure occurs with encoded latin1
> characters.
>
>
> SEND
> destination:/queue/jstevenson@jstevenson2.msgtest2
> content-length:59
>
> Wed Jul 20 10:32:50 2011 utf8 encoded: unicode >☻< smiles[NUL]
>
>
>
> I will ping the Net::Stomp maintainer about this as well, but it does seem
> like
> there might be a problem in the receiving Stomp protocol handler.  The docs
> about
> the use of the content-length header being used as a trigger for handling
> the message
> as either a BytesMessage or a TextMessage are a little unclear to me:
>
> It is recommended that SEND frames include a content-length header which is
> > a byte count for the length of the message body. If a content-length
> > header is
> > included, this number of bytes should be read, regardless of whether or
> > not
> > there are null characters in the body. The frame still needs to be
> > terminated
> > with a null byte and if a content-length is not specified, the first null
> > byte
> > encountered signals the end of the frame.
>
> (emphasis mine around "The frame").  This looks like it's saying that the
> content-length should indicate the length of the body not including the
> frame's terminating null byte while the frame itself is still terminated by
> the
> null byte which is not included in the content-length header figure.  This
> does
> appear to be what the Net::Stomp library is doing; but am I missing
> something?
>
>
> Thanks again for any clarification and help.
>
>
> -Joel
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Non-ASCII-messages-via-Stomp-being-dropped-or-mangled-in-5-5-tp3679601p3681683.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message