Python kernel tries to connect until it disconnects completely


I am currently trying to implement Jupyter Lab and Jupyter Notebook in our Rstudio environment.

When I start the Jupyter Lab session, the python kernels (version 3 and 3.9.5) are disconnected but try to connect continuously, until they are disconnected.

So I can't execute python code.

The console warning and error are the following:

Connection lost, reconnecting in 29 seconds.

and :

WebSocket connection to 'wss://' failed:
_createSocket	@	jlab_core.a8a3519a13…3519a137e0ddfc2a4:2

Can you help me please ?

Welcome to RStudio Community @alain!! And thanks for asking!!

Unfortunately the websockets in jupyter are known to be a pernicious problem in enterprise environments. VS Code sessions also depend on websockets, as does running a Shiny application within an RStudio session.

At a glance, it looks like the websocket is getting closed by a proxy between your browser and the RStudio Workbench server. Do you know if there is a proxy involved in the web traffic here? Sometimes organizations have firewall rules that block websockets over the HTTP (unencrypted) protocol too.

In any case, we have some guidance on enabling websockets for some common proxies here:

If you keep running into troubles, this is definitely something you can reach out to our professional support team about, as well! You can email, share a link to this discussion, and ideally run a diagnostic report.

I hope that helps! :smile:

1 Like

Hello @cole , thank you for your answer !

Unfortunately, being new in my company I don't know if there is a proxy that blocks it.

Do you know if there is a way to see it in the code or otherwise?
Or should I ask someone in the company who is in charge of this part?

Thanks again for your help :slight_smile:

Oops. I was off on vacation and totally missed this :sweat_smile:

Always feel free to reach out to your RStudio Customer Success representative if you are having trouble with this sort of thing and need a sounding board / direction :smile:

There are certain types of diagnostics and such you can do, but it's probably easiest to find the "person responsible" for this type of thing in your org. Usually it's someone in the IT organization, so maybe whoever manages the server or performs patches - who you would go to for elevated privileges or if the server went down (i.e. you couldn't SSH into it, etc.).

I hope that's helpful! Definitely let me know if you run into other issues or if you want to try to do more diagnostics yourself :smile: