Seems to me that 2 nulls is an error. The normal case, is just 1 null being sent. I would open it up as an issue.
On Thu, Jun 25, 2009 at 12:29 AM, matt walsh <matthew.wa...@gmail.com>wrote: > > Hi All, > > I have had a problem connecting to OpenMQ via stomp using Apache NMS. It > seems the NMS code terminates stomp frames using a 'NULL' character (as per > the stomp spec), which is defined in the class StompFrameStream as follows > > public const char NULL = (char) 0; > > OpenMQ was giving me errors because it seems from my investigations that > this 'NULL' is infact a double byte character and is therefore sending 2 > zeros at the end of a frame. This leaves an extra NULL lying around in the > stream that OpenMQ is unhappy with, breaking further commands sent for a > session. > > I have patched the NMS source to define NULL as a byte, ie > > public const byte NULL = (byte) 0; > > This makes the problem go away for OpenMQ. > > I would like some advice on this. Is it acceptable for a Stomp frame to > have > additional NULL characters lying around as NMS seems to be doing (and thus > is this a problem that should be dealt with by OpenMQ) or should NMS be > patched in a way similar to what I have done here? > > I have attached my patched version of the 1.0 version of StompFrameStream. > http://www.nabble.com/file/p24196808/StompFrameStream.csStompFrameStream.cs > -- > View this message in context: > http://www.nabble.com/Using-NMS-to-connect-to-OpenMQ-via-stomp-tp24196808p24196808.html > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. > > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://fusesource.com/
