Skip to content
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

Initial websocket request can fail #105

Open
consideRatio opened this issue Mar 30, 2024 · 3 comments
Open

Initial websocket request can fail #105

consideRatio opened this issue Mar 30, 2024 · 3 comments

Comments

@consideRatio
Copy link
Member

consideRatio commented Mar 30, 2024

I've not been able to pinpoint the reason, but it seems like the initial attempt to connect to a VNCserver via websockets when visiting /desktop can sometimes fail. I suspect its a race condition that may make it never happen in some contexts, and often in others.

In #101 there is now a test that often but not always in our CI system on the first attempt, but not the second.

Debugging

  • I've not reproduced this by visiting /desktop on my laptop for tiger or turbo, but I think it does from my desktop computer
  • Reproduced using dockerspawner, as seen on the fourth attempt in this GIF:
    sometimes fails on startup
@consideRatio
Copy link
Member Author

Ideas on why

  1. viewer.js client sends a websocket handshake before websockify is ready to listen
  2. websockify receives a websocket handshake before vncserver is ready to listen
  3. jupyter-server-proxy's issue WebSocket subprotocols for client/proxy are chosen without asking the server we proxy to jupyter-server-proxy#459 behavior of accepting the client/proxy websocket handshake before the proxy/server handshake.

@consideRatio
Copy link
Member Author

I've seen this show up more consistently when the ping is notable (by testing against a hub deployed in USA from Sweden). Three out of three tests made this happen on first attempt to visit /desktop, while doing things locally I just observed it one out of four for example.

consistent-reproduction-remote

@sunu
Copy link
Contributor

sunu commented May 31, 2024

@consideRatio I ran into this issue while working on NASA-IMPACT/veda-jupyterhub#2. I have opened a PR with a proposed workaround in #112. Please let me know if that looks reasonable.

sunu added a commit to sunu/jupyter-remote-qgis-proxy that referenced this issue Jun 5, 2024
Related to jupyterhub/jupyter-remote-desktop-proxy#105.

When QGIS starts before VNC connection is established, the QGIS process doesn't get attached to the VNC session and runs in the background.

We wait for the VNC connection to be established to make sure the QGIS GUI shows up in the VNC session.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants