websocket issue
Added by mat Sch over 12 years ago
Upgraded to 3.3.0 and i'm having websocket issues. Was working fine in 3.2.1. I see the initial messages being sent from the browser arriving to my app, but then see a disconnect. The chome debugger reports,
WebSocket connection to 'ws://192.168.22.125:8080/ljaudioWidget?wtd=qPZouB2omKWfwo83&wtd=qPZouB2omKWfwo83&request=ws' failed: Compressed bit must be 0 if no negotiated deflate-frame extension
*Using the whttp connector.
*don't think i'm using zlib compression
*tryed chrome and firefox with simular results
Any advice?
Thanks,
-matt
Replies (6)
RE: websocket issue - Added by Koen Deforche about 12 years ago
Hey,
Could you see if latest git fixes or improves this (there are a number of improvements related to WebSockets there) ?
I also see this occasionally but haven't found a way to reproduce it easily. Perhaps you have more information for a test case that reproduces this consistently ?
Regards,
koen
RE: websocket issue - Added by mat Sch about 12 years ago
Tried the latest(4/26) from git. No difference. It still happens 100% of the time for me. Here's what I'm doing,
WT->browser, sends javascript via doJavaScript
browser->WT, browser handles the function and emits a response to my WT program
WT->browser, wt handles the response(JSignal) and sends javascript via doJavaScript. The error happens when sending the javascript to the browser. The javascript never arrives and the console displays the error above.
I could provide network captures if that would help.
Thanks,
-mat
RE: websocket issue - Added by Koen Deforche about 12 years ago
Hey mat,
I am glad you have a case that reliably reproduces it.
A test case that does just that and/or network captures would be helpful!
Regards,
koen
RE: websocket issue - Added by Voice Vox about 12 years ago
Hi,
I can confirm that this annoying issue indeed happens for us as well even with the latest version of the Wt.
As we have noticed it happens as a result of several "server pushes" made via WServer::post (or most likely when the triggerUpdates() is called afterwards). It happens not instantly, but rather after a certain time or may be a certain number of Server Pushes. Not much of a regularity that we have notice, but it happens always (!). Can be cured only with a full app reload (termination).
It happens with Chrome, FF, IE so it cannot be a result of a single browser's protocol misinterpretation.
We had to switch off the use of web-sockets which in fact badly affects the performance of dynamic updates.
Could you please take a look at this issue or at least point out to us where you form these web-socket headers so that we can try fix it ourselves?
RE: websocket issue - Added by Koen Deforche about 12 years ago
Hey,
I responded to the bug report in the same ways as my initial responses here. I think we need to reproduce this to be able to move this forward.
We format a web socket message in WtReply.C, in nextContentBuffers()
I suspect the issue is caused not by a mis-encoding here, but rather by some race condition / multi-threading issue which messes up the way we send messages, for example by concurrently trying to send two messages at the same time on a single connection?
It would perhaps be useful to obtain a trace from a debug build with debug logging for the http-fronted enabled (-debug +debug:wthttp +debug:wthttp/async)
Regards,
koen