<div dir="ltr">Thanks for your answer!<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>Jonatan Kallus wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Problem is that the frames sent back from rabbitmq does not seem to be<br>
terminated with a null character. The 'CONNECTED' frame ends with an<br>
empty line and the 'MESSAGE' frame just ends.<br>
</blockquote>
<br></div>
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.<div></div></blockquote><div><br>
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.<br>
<br>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.)<br>
<br>
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:<br>
<br><blockquote>Michael Caplan wrote:<br>As an aside, on re-reading the protocol, I'm wondering if our scan for<br>end of frame is incorrect (or specific to ActiveMQ's implementation). A<br>frame is terminated by a \x00, and not \x00 + \n according to the spec:<br>
<br>"...the null indicates the end of the frame."<br><br>Mike<br><br>Jonatan Kallus wrote:<br>> Yes, the space between 'login:' and '<username>' was interpreted as<br>> part of the username.<br>
><br><br>Michael Caplan wrote:<br>Huh. That's a tricky one. The protocol does not specify a space<br>between the header key:value combinations, but the protocol examples do<br>use a space. I'm hesitant to call this a protocol implementation bug on<br>
the client. I think you should push back on the MQ developers on this<br>one to.<br><br>Best,<br><br>Mike<br></blockquote></div><div><br></div>
</div><br></div>