You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, can you tell me what was the symptom given by this problem.
We have and issue where sockets get disconnected with this error:
error: uncaptured python exception, closing channel <websocket._Dispatcher at 0x5bfa908> (<type 'exceptions.AssertionError'>: [/usr/lab/jakarta-jmeter-2.4/bin/Python-2.7.1/Lib/asyncore.py|read|79] [/usr/lab/jakarta-jmeter-2.4/bin/Python-2.7.1/Lib/asyncore.py|handle_read_event|445] [/usr/local/lib/python2.7/site-packages/websocket.py|handle_read|146] [/usr/local/lib/python2.7/site-packages/websocket.py|_read_until|169] [/usr/local/lib/python2.7/site-packages/websocket.py|_handle_frame|172])
And I was wandering if this bug could be the cause.
Thank you.
Part of the exception gets eaten by the HTML code, anyway the exception type is 'exceptions.AssertionError' and the assert seems to be the one in _handle_frame, and _handle_frame is the callback function called by _read_until
This is an absolute must patch. I was having tremendous troubles with frame shifting issues. _read_until was mis-parsing things and the handle_header assertion would get broken because an \xff character would be at the end instead of just \r\n\r\n. This problem also came up in handle_frame - some frames would have an \xff at the start and end of the frame because read_until was leaving the frame open too long. For some reason this never happened to me when I was making just one socket, but for large numbers of sockets (I'm trying to load-test a socket.io server) it happened quite frequently.
Thanks so much for the fix, hamax. You're a life-saver! I was about to report this bug myself and then throw up my hands and go re-implement the whole thing in Java.
Activity
mordicuac commentedon Jun 20, 2011
works for me, thanks
acid-head commentedon Nov 14, 2011
Hi, can you tell me what was the symptom given by this problem.
We have and issue where sockets get disconnected with this error:
error: uncaptured python exception, closing channel <websocket._Dispatcher at 0x5bfa908> (<type 'exceptions.AssertionError'>: [/usr/lab/jakarta-jmeter-2.4/bin/Python-2.7.1/Lib/asyncore.py|read|79] [/usr/lab/jakarta-jmeter-2.4/bin/Python-2.7.1/Lib/asyncore.py|handle_read_event|445] [/usr/local/lib/python2.7/site-packages/websocket.py|handle_read|146] [/usr/local/lib/python2.7/site-packages/websocket.py|_read_until|169] [/usr/local/lib/python2.7/site-packages/websocket.py|_handle_frame|172])
And I was wandering if this bug could be the cause.
Thank you.
acid-head commentedon Nov 14, 2011
Argh,
Part of the exception gets eaten by the HTML code, anyway the exception type is 'exceptions.AssertionError' and the assert seems to be the one in _handle_frame, and _handle_frame is the callback function called by _read_until
drewww commentedon Nov 29, 2011
This is an absolute must patch. I was having tremendous troubles with frame shifting issues. _read_until was mis-parsing things and the handle_header assertion would get broken because an
\xffcharacter would be at the end instead of just\r\n\r\n. This problem also came up in handle_frame - some frames would have an\xffat the start and end of the frame because read_until was leaving the frame open too long. For some reason this never happened to me when I was making just one socket, but for large numbers of sockets (I'm trying to load-test a socket.io server) it happened quite frequently.Thanks so much for the fix, hamax. You're a life-saver! I was about to report this bug myself and then throw up my hands and go re-implement the whole thing in Java.