Skip to content


Subversion checkout URL

You can clone with
Download ZIP


(0.9.5)XHR polling - multiple/simultaneous requests cause data corruption and "transport discarded" event #816

gubarez opened this Issue · 8 comments

4 participants


The following post is not really relevant... since the real issue is described in the second post. Read this one to have glimpse on the debug log.

Hi guys!

I have added clustering to my server-app. Since then, there is a problem with xhr-polling requests. This issue occurs on clients running Android browsers - both webview and native, since Android browser doesn't support websockets. Looks like the transport is discarded immediately after the successfully emitted JSON object with encoded UTF8 data and having Cyrillic (may be other non-Latin) characters. After that, the next 1-2 (may be more) requests made by the client are passed to the server, however, seems like it does not recognizes them. Looks like something is causing some kind of data corruption. Please see the debug log below:

debug - xhr-polling received data packet 5:::{"name":"request0","args":[{"lat":42,"lon":23}]}
debug - setting request GET /
debug - setting poll timeout
debug - clearing poll timeout
debug - xhr-polling writing 5:::{"name":"retCB","args":[{"data":"текст"}]}
debug - set close timeout for client 3999143631481520554
debug - discarding transport
debug - cleared close timeout for client 3999143631481520554
debug - xhr-polling received data packet �88�5:::{"name":"request1","args":[{"lat":42"lon":23}]}�93�5:::{"name":"request2","args":[{"lat":42,"lon":23}]}
debug - setting request GET /
debug - discarding transport
debug - cleared close timeout for client 3999143631481520554

What happens in the background:
1. First I have a kind of login - nothig special - just facebook auth data transported...
2. Load data request from the client - server responds properly.
-- at this point the transport is discarded
-- meanwhile (the client sends request1 and request2)
3. The "request1" is coming to the server application (socket.on('request1', etc...) is invoked), and you can see from the above - the server is sending its data... however, since the transport is discarded, the client does not receive anything.
4. As you can see from the above, "request2" is also "a kind of" received by the daemon, but since "the data corruption" - nothing happens in the server application, probably because the "closed', hence "deleted" connection...

Important: The client is not informed for any events and does not detect any events about changes in the connection state - no connect, disconnect, error, reconnect, close, retry events were invoked. Running redis-cli - to monitor the transport - nothing unusual happens.

Another observation - I have noticed that sometimes - cannot control this - the "Cyrillic" data transmission causes the node application and console to block (I'm using ssh(putty) connection). Not even CTR+C works.

Using Socket.IO 0.9.5 both server- and client-side.Running on CentOS 6 with, Node.js 6.12 and latest stable version 2.4.10 of Redis Server.

I have no idea what is causing the problem... Any guesses?

p.s. There aren't any problems when using websockets.
p.p.s. here is another guy, who have similar problem.


OK, I finally got this! The problem does not have anything to do with the UTF-8 encoding and the Cyrillic characters, nor the data format. It just coincides with the real issue.
As described earlier - after the login data request and later authorization, then follow three immediate requests. Hence they are almost in the same moment, something happens with the daemon, so it discards the following requests after the first one has received. The solution is to send requests one by one with certain delay e.g. 500ms or to wait a response from the server to send the next request... Although the problem is clear, I don't know how to fix it. However, I believe it is a problem between the Redis store and the manger. Something I found is that when sending such data, in the Redis.prototype.publish function (redis.js 105 line), the args has extra element which is undefined - {'0':'id','1':data,undefined}. What causes this, I couldn't find....

p.s. To admins - seems like the title does not have anything to do with the current issue, so may be the name should be different or removed. As I see, may be the described issueis similar with this one - #438 but yet in 0.9.5 the issue is not fixed. If you decide to keep the topic open, I suggest for a title something like: '(0.9.5)XHR polling - multiple/simultaneous requests cause "transport discarded" event when using clustering (w/ redis server).


@gubarez I have this issue #438 but seems like not fixed in 0.9.5, did you find the solution?


@inamabbas As I stated - the temporary solution I find is to send the requests one by one either by having a delay (btw I have found 500ms is not enough, 1sec is better) or by waiting a response from the server for the previous request. I don't have any idea where exactly the problem occurs.


OK, I have a new input here...

I've just tried with the store and there was no difference at all... So I believe it is a kind of store-xhr-polling modules communication problem.


Hey there!
I am still stick on this issue, since the delay doesn't really help much as a workaround.... I have prepared a test case... During my investigation on the issue, I have found that may be the there is no problem with the Redis store at all, since I have to replicated the bug without using clustering. Actually it seems to occur when the client emits data, while the server is in the process of emitting data to the client (and later-on discarding the transport). The issue seems to occur with JSONP Polling too.

Here is a test case. Note, you may need a big chunk of file, like 100kb or so, to be able easily replicate the issue. My test text file:

Here is the server-side code:

var io = require('', {'log level': 1}).listen(2020);
var fs = require('fs');

var buf = "";
var input = fs.readFile('./a.txt', function(err, data) {
buf = data.toString();

io.sockets.on('connection', function(socket) {

socket.on('a', function() {
socket.emit('data1', buf);

socket.on('b', function () {
socket.emit('data2', buf);

Here is the client-side code:

Basically, the server listens for events, named 'a' or 'b', and then emits the contents of the file. The client emits very fast 100 'a' and 'b' requests. You can see in the console what happens... Note, you need to increase the buffer of the console.

I was wondering, why it is necessary to discard the transport after emitting data from the sever... Is it a bug, or this should be a normal behavior?


well... it turned out not to be a server-side problem... The issue is form the client-side - socketio/ but actually it occurs also in Desktop Chrome, so may be it is coming from the webkit engine in general.

@gubarez gubarez closed this

@gubarez I just tried this fix (by running the newest code from master) and I'm still getting:

node_redis: no callback to send error: Error: ERR wrong number of arguments for 'hset' command
Error: Error: ERR wrong number of arguments for 'hset' command
    at HiredisReplyParser.<anonymous> (/Users/lukegalea/Development/skunkworks/node_modules/
    at HiredisReplyParser.emit (events.js:67:17)
    at HiredisReplyParser.execute (/Users/lukegalea/Development/skunkworks/node_modules/
    at RedisClient.on_data (/Users/lukegalea/Development/skunkworks/node_modules/
    at Socket.<anonymous> (/Users/lukegalea/Development/skunkworks/node_modules/
    at Socket.emit (events.js:67:17)
    at TCP.onread (net.js:347:14)
@yapiskan yapiskan referenced this issue in pkyeck/socket.IO-objc

socket disconnects continiously at xhr polling... #83


@gubarez Do you have the client code that would reproduce this? Do you know if the issue has been fixed in the 0.9.16?

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.