SockJS message delivery order

187 views
Skip to first unread message

mrtn

unread,
May 8, 2013, 5:43:44 PM5/8/13
to soc...@googlegroups.com

Hi,

I'm using SockJS-client 0.3.4 and SockJS-Tornado on the server-side. In the client, I have some code like this:

...
conn.send(msg1);

if (...) {
    conn.send(msg2);
}
...

I've discovered in the server log that, msg2 is actually received before msg1 for some clients. The protocol used is xhr_streaming. I wonder if SockJS provides any guarantee for the order of message delivery, if so, is it applicable to all supported protocols? If not, how can I make sure that, in the code like above, msg1 is delivered before msg2?

Serge S. Koval

unread,
May 8, 2013, 5:46:28 PM5/8/13
to Merton Lister, sockjs
Does it happen every time or it happens occasionally?

Did you see this error with any of the polling transports?


--
You received this message because you are subscribed to the Google Groups "sockjs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sockjs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

mrtn

unread,
May 8, 2013, 6:06:32 PM5/8/13
to soc...@googlegroups.com, Merton Lister

I cannot be certain that if it happens every time, as the logic of sending msg2 is rarely triggered (it is still important to the application). But so far on 2 occasions I can observe, I see msg2 is processed by the server before msg1.

As for other polling transports, I do not know. Currently, this is the list of protocols we use: ['websocket', 'xdr-streaming', 'xhr-streaming', 'xdr-polling', 'xhr-polling', 'iframe-eventsource'], and so far we've got either websocket or streaming protocols.

Is this expected behavior specific for streaming protocols? As for websocket, I would imagine the order should be guaranteed?

Serge S. Koval

unread,
May 8, 2013, 6:21:43 PM5/8/13
to Merton Lister, sockjs
In both cases sockjs client should send messages in proper order, as there's explicit outgoing buffering happening for polling/streaming transports: https://github.com/sockjs/sockjs-client/blob/master/lib/trans-sender.js#L15
If sockjs client is sending something, all subsequent outgoing data will be queued. Unless there's error in the client, it should work properly.

sockjs-tornado will receive and process messages one by one: https://github.com/mrjoes/sockjs-tornado/blob/master/sockjs/tornado/session.py#L419

I modified sockjs-tornado chat sample to send two messages instead of one and incremental message number with each one. I tried it against localhost and can't reproduce issue with any of the transports.

So, I guess this is something else. Without logging, I'd think that:
1. Server receives first message and starts processing it.
2. While handling, it might do some asynchronous operation
3. Server starts handling second message before asynchronous operation is complete
4. There's race condition and exception happens

Can you confirm that message logging happens before any asynchronous calls?

Serge.

Rossen Stoyanchev

unread,
May 15, 2013, 9:43:02 AM5/15/13
to soc...@googlegroups.com

FWIW, this can happen on Servlet containers where each incoming request is processed in a separate thread, in parallel. So if two messages arrive around the same time, it cannot be guaranteed which one will be processed first. Not sure if this is relevant to Tornado or not.

Rossen


Reply all
Reply to author
Forward
0 new messages