[rabbitmq-discuss] Stomp frame not terminated with null character

[Jonatan Kallus]

Thanks for your answer!

Jonatan Kallus wrote:
>
>> Problem is that the frames sent back from rabbitmq does not seem to be
>> terminated with a null character. The 'CONNECTED' frame ends with an
>> empty line and the 'MESSAGE' frame just ends.
>>
>
> That's strange. How have you determined this? The code in stomp_frame.erl
> always generates a NUL byte for transmission, and other STOMP clients seem
> to have no trouble.
>

The read loop in the php stomp client keeps reading until it finds a null
character, and it does not stop until a time out is reached. I tried to
tweak this in a few different ways without any positive results. There might
be something I am missing in the way php handles socket connections and/or
null characters in strings. Either way, the php stomp client doesn't work
with the stomp gateway 'out of the box' but it seems like people are using
it successfully with ActiveMQ or JMS.

I am only going to use the php/stomp connection to send messages into the
queue, so I hardcoded recognition of CONNECTED and RECEIPT for now, that is
propably the only two I will need. (Failing on anything else.)

Below is a copy of a conversation I had on the mailinglist for php stomp. It
suggests that the problem might be that the client is looking for an
ActiveMQ specific ending sequence of 'NULL-NEWLINE', but I tried to correct
that and I am pretty sure that is not the cause:

Michael Caplan wrote:
As an aside, on re-reading the protocol, I'm wondering if our scan for
end of frame is incorrect (or specific to ActiveMQ's implementation).  A
frame is terminated by a \x00, and not \x00 + \n according to the spec:

"...the null indicates the end of the frame."

Mike

Jonatan Kallus wrote:
> Yes, the space between 'login:' and '<username>' was interpreted as
> part of the username.
>

Michael Caplan wrote:
Huh.  That's a tricky one.  The protocol does not specify a space
between the header key:value combinations, but the protocol examples do
use a space.  I'm hesitant to call this a protocol implementation bug on
the client.  I think you should push back on the MQ developers on this
one to.

Best,

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080918/ee78e1f8/attachment.htm