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 <jsteven...@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. >
