{"action":"created","issue":{"url":"https://api.github.com/repos/socketio/socket.io-client-java/issues/250","labels_url":"https://api.github.com/repos/socketio/socket.io-client-java/issues/250/labels{/name}","comments_url":"https://api.github.com/repos/socketio/socket.io-client-java/issues/250/comments","events_url":"https://api.github.com/repos/socketio/socket.io-client-java/issues/250/events","html_url":"https://github.com/socketio/socket.io-client-java/issues/250","id":117205878,"number":250,"title":"Consistent \"xhr poll error\" is caused by hanging instances of XHRPolling","user":{"login":"oliverhausler","id":8090341,"avatar_url":"https://avatars.githubusercontent.com/u/8090341?v=3","gravatar_id":"","url":"https://api.github.com/users/oliverhausler","html_url":"https://github.com/oliverhausler","followers_url":"https://api.github.com/users/oliverhausler/followers","following_url":"https://api.github.com/users/oliverhausler/following{/other_user}","gists_url":"https://api.github.com/users/oliverhausler/gists{/gist_id}","starred_url":"https://api.github.com/users/oliverhausler/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/oliverhausler/subscriptions","organizations_url":"https://api.github.com/users/oliverhausler/orgs","repos_url":"https://api.github.com/users/oliverhausler/repos","events_url":"https://api.github.com/users/oliverhausler/events{/privacy}","received_events_url":"https://api.github.com/users/oliverhausler/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":17,"created_at":"2015-11-16T20:01:05Z","updated_at":"2015-11-28T17:22:34Z","closed_at":null,"body":"#241 may be related\r\n\r\nA consistent \"xhr poll error\" seems to be caused by hanging connections. The condition is typically caused when manager calls onclose() and interrupts a pending xhr request.\r\n\r\nThe error does typically never occur as long as xhr requests are serviced by the server, e.g. a packet is returned while the request is pending. The client then receives the packet and posts a new request.\r\n\r\nTimeouts play a significant role. The client can only recover from the condition, if the maximum timeout imposed by reconnectionDelayMax is large enough to ensure the previous request has been cancelled. If it is still pending, then the new request will immediately fail as well, get stuck, and block the next poll request.\r\n\r\nThis is the reason why it sometimes takes extremely long, until a client recovers from disconnects. When connection is retried, the backoff timeout is reset to reconnectionDelay, then increased. Reconnect attempts fail for a long time, until the gap is large enough.\r\n\r\nThis issue may exclusively happen or happen worse on Android 4.2 (SKD 17) [probably 4.1-4.3]. As it seems, there is an underlying network problem when handling long-running requests (see #248). I could not see any relationships between size of connection pool and such, but I could see that sometimes multiple requests have been pending in parallel. It looks like it works fine as long as there is a single pending request, but it fails (always or often) if 2 or more long running requests are pending.\r\n\r\nI tried using okhttp-urlconnection instead of Android's HttpUrlConnection, but this did not make it any better. The issue is just better debuggable, but it remains. Another indicator that we probably have a networking issue here.\r\n\r\nHow to reproduce:\r\n\r\n- set upgrade = false, so we only have xhr polling\r\n- open a socket\r\n- provoke a network outage\r\n- hope the client goes into the \"xhr poll error\" loop\r\n- watch how it does not recover\r\n- in Manager, set a breakpoint AFTER this line:\r\n\r\n        `this.reconnecting = true; // ln 501`\r\n\r\n- wait long enough to ensure all pending xhr connections have been timed out\r\n- keep running the code\r\n- watch how the client reconnects and recovers\r\n"},"comment":{"url":"https://api.github.com/repos/socketio/socket.io-client-java/issues/comments/160321946","html_url":"https://github.com/socketio/socket.io-client-java/issues/250#issuecomment-160321946","issue_url":"https://api.github.com/repos/socketio/socket.io-client-java/issues/250","id":160321946,"user":{"login":"pakon","id":31494,"avatar_url":"https://avatars.githubusercontent.com/u/31494?v=3","gravatar_id":"","url":"https://api.github.com/users/pakon","html_url":"https://github.com/pakon","followers_url":"https://api.github.com/users/pakon/followers","following_url":"https://api.github.com/users/pakon/following{/other_user}","gists_url":"https://api.github.com/users/pakon/gists{/gist_id}","starred_url":"https://api.github.com/users/pakon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pakon/subscriptions","organizations_url":"https://api.github.com/users/pakon/orgs","repos_url":"https://api.github.com/users/pakon/repos","events_url":"https://api.github.com/users/pakon/events{/privacy}","received_events_url":"https://api.github.com/users/pakon/received_events","type":"User","site_admin":false},"created_at":"2015-11-28T17:22:34Z","updated_at":"2015-11-28T17:22:34Z","body":"Interesting observation. \r\n\r\nWhen we try to connect to \"socket.io\" server directly from \"socket.io\" client on Android 4.2.2 we are always disconnect by the server. But if we are using \"AWS ELB\" with sticky session in front of our \"socket.io\" server the client socket not disconnected.\r\n\r\nThis situation needs to be investigated to understand what happens when \"AWS ELB\" is in front of server."}}