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.
