Open martinheidegger opened 10 years ago
Are you running on a remote server that doesn't support websockets? That could cause trouble El sep 7, 2014 3:28 PM, "Martin Heidegger" notifications@github.com escribió:
In my current build setup I have to wait for something to finish and since it takes a while I will only test the connection every 2 seconds. It seems though as if the strider output streaming seems to be stuck if there is no output for longer time (i need to refresh to get the current output). Could it be that the output logging doesn't "ping"?
— Reply to this email directly or view it on GitHub https://github.com/Strider-CD/strider/issues/564.
It is a remote server but I don't know what you mean with "server supports websockets"?
Some proxies don't like websockets, which could result in degraded behavior on the build page El sep 7, 2014 5:33 PM, "Martin Heidegger" notifications@github.com escribió:
It is a remote server but I don't know what you mean with "server supports websockets"?
— Reply to this email directly or view it on GitHub https://github.com/Strider-CD/strider/issues/564#issuecomment-54765006.
Is there a indicator in strider that would tell me if its using websockets or not?
@martinheidegger your browser can tell you that in the Network tab of the inspector
Alright, there is an error...
WebSocket connection to 'wss:// [ mydomain ] /socket.io/1/websocket/SGer5OgjW0dfTerqIigC' failed: Error during WebSocket handshake: Unexpected response code: 502
So: Do I assume right that any error here will result in the ui to not work properly? If so: Shouldn't it just refresh the data (to be sure) in an interval? (maybe put out a warning that strider is slower because of that?)
@martinheidegger
10.5.3 502 Bad Gateway
The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.
So this indicates there is a proxy problem. What proxy are you using? What's your configuration like for that proxy? Remember that configuring a proxy in front in addition to webckets in addition to SSL becomes more and more complex and leaves more and more room for error when configuring these things.
I assume its because I run strider in a docker instance that uses nginx to pass through the ports (elastic beanstalk). Never the less i would like to empathise two points: 1) The connection should not break just because websockets are not available (bug?!) 2) It would be good to have a indicator show to admins that the connection is not using websockets and how to resolve this issue.
We're using socket.io, which should gracefully fall back to long polling... El sep 8, 2014 12:27 AM, "Martin Heidegger" notifications@github.com escribió:
I assume its because I run strider in a docker instance that uses nginx to pass through the ports (elastic beanstalk). Never the less i would like to empathise two points: 1) The connection should not break just because websockets are not available (bug?!) 2) It would be good to have a indicator show to admins that the connection is not using websockets and how to resolve this issue.
— Reply to this email directly or view it on GitHub https://github.com/Strider-CD/strider/issues/564#issuecomment-54780794.
should but doesn't ?!
@martinheidegger you need to specify certain options in nginx to handle sockets, also what version of nginx are you using? Because there are issues with before a certain version.
The following needs to be added to your location block:
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
Also we have a long running PR #525 which updates socket.io to 1.0+ which might solve the issue if it was something to do with sio.
@martinheidegger It's funny that you say the issue occurs for you when there is no output for a long time. Sometimes I have an issue that sounds very similar to this when it appears there is too much input coming in too quickly. Then the log stops spitting out anything and the UI is unreceptive to clicks. I'm curious to know whether your UI stays responsive during this issue.
From my POV, sometimes my project view will freeze up indefinitely, or a little while after the job has finished. I've wondered if this is socket.io overloading the browser with events. It usually occurs during either npm install
or npm test
i.e. when the console is firing out a lot of output quickly. Sometimes I just manually close the tab and reload to watch the input again and at work we typically stay on the dashboard page.
I just did a little bit of JS profiling in Chrome (on version 1.5 and on your browserify branch @knownasilya ) and I notice that the project view consumes anywhere from 40% - 50% of CPU when the job is running.
@bitwit I agree, I've had issues with it being unresponsive as well, and a refresh always did the trick. Might be a good idea to revisit the implementation that we have.
In my current build setup I have to wait for something to finish and since it takes a while I will only test the connection every 2 seconds. It seems though as if the strider output streaming seems to be stuck if there is no output for longer time (i need to refresh to get the current output). Could it be that the output logging doesn't "ping"?