Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Possible parsing issue #33

omarkj opened this Issue · 3 comments

2 participants


When sending buffered messages, only some of them are received by the server. buffers up messages as such:

It seems like only Message0 would be received here. I'm trying to confirm this atm.


That sounds funny.

The implementation should stop handling them when the length is right and return.

I can think of a few reasons:

  1. are both messages submitted at once? If so, the parser will read the first header, catch the length, keep that and drop the rest. If it needs to be able to handle many messages that way, it should be easy enough to do, although we'll need to define an API for that.
  2. do the messages start by ~h~ or ~j~? As far as I know, the heartbeat one should be handled fine, but the json one will then go through the jsx parser, which might just never complain about it and keep looping in the continuation-based API.

It sounds likely it's number 1. Is this some part of the standard protocol that you should be able to just append messages to each other?


After a discussion, we've decided it is likely option no.1 that happens, especially with long polling calls that might buffer them up.

While we would probably need a test case to document everything, I'll just change the parser to return a list of messages if more than one exists.

Seeing the following:

because we use gen_event to handle everything, I should be able to change the bits of code similar to the one above for something that just sends many notices. No messages should be lost after that.


This is fixed in 16815ab

Note that it is assumed that the first message of the string is the first one received.

@ferd ferd closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.