-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems after upgrading to latest tornado and sockjs-tornado #67
base: master
Are you sure you want to change the base?
Conversation
First issue probably solved by 7153769. |
No, problem with websockets still not solved.It can be reproduced by sending unexpected values in By the way, is there any reasons to override this method? Both |
Can confirm the bug in issue 1 above still exists for anyone using Tornado >=4.0. Unfortunately I think @dimabxsx's proposal is a breaking change for anyone still using 3.2 (or lower, god forbid...). The checks for I don't know of a clean way of supporting both versions, so this may just mean a hard dependency on 3.2 here. |
Only reason why _execute() was overridden - there are client-side SockJS tests and sockjs-tornado had to be compliant. Older Tornado versions didn't have this checking logic in place. Second issue - not sure what's going on. Will try to troubleshoot. Most likely caused by some additional checks in Tornado or sockjs-tornado to send something to the client on closed connection. |
The second issue is caused by closing the connection from within def do_close(self):
self.close()
def on_open(self, data):
...
IOLoop.current().add_callback(self.do_close) |
After switching to the latest tornado and sockjs-tornado stuck with this exceptions.
First one comes from
SockJSWebSocketHandler._execute
Can't reproduce this. Checking
self.stream
value beforewrite
andclose
do the job, but i'm not sure it's a good solution.Second one is related to xhr-polling transport.
Caused by calling
SockJSConnection.close
when using xhr-polling.Can be reproduced in chat example.
self.close()
call somewhere inChatConnection.on_message
When
close
will be called, you'll get same exception.