From 7d30935ec61ebed744cd471dafa9b250a6519375 Mon Sep 17 00:00:00 2001 From: "Maarten A. Breddels" Date: Wed, 2 Oct 2024 13:16:33 +0200 Subject: [PATCH] docs: explain and warn about the implications of multiple workers --- .../advanced/content/20-understanding/50-solara-server.md | 3 ++- .../getting_started/content/07-deploying/10-self-hosted.md | 4 +++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/solara/website/pages/documentation/advanced/content/20-understanding/50-solara-server.md b/solara/website/pages/documentation/advanced/content/20-understanding/50-solara-server.md index 256ad6dcb..9f827eb30 100644 --- a/solara/website/pages/documentation/advanced/content/20-understanding/50-solara-server.md +++ b/solara/website/pages/documentation/advanced/content/20-understanding/50-solara-server.md @@ -38,7 +38,8 @@ Each virtual kernel runs in its own thread, this ensures that one particular use ## Handling Multiple Workers -In setups with multiple workers, it's possible for a page to reconnect to a different worker than its original. This would result in a loss of the virtual kernel (since it lives on a different worker), prompting the Solara app to initiate a fresh start. To prevent this scenario, a sticky session configuration is recommended, ensuring consistent client-worker connections. Utilizing a load balancer, such as [nginx](https://www.nginx.com/), can achieve this. + +In setups with multiple workers, it's possible for a page to (re)connect to a different worker than its original. This can happen after a lost network connection is restored, or when [ipypopout](https://github.com/widgetti/ipypopout) is used, since ipypopout creates a new connection, which can end up at a different worker. This can result in a loss of the virtual kernel, since it lives on the worker that was first connected to. The Solara app will then initiate a fresh start, or simply fail when ipypopout is used. To prevent this scenario, a sticky session configuration is recommended, ensuring consistent client-worker connections. A load balancer, such as [nginx](https://www.nginx.com/), can be used to achieve this. Note that using multiple workers (e.g. by using gunicorn) cannot work since a connection will be made to a different worker each time. If you have questions about setting this up, or require assistance, please [contact us](https://solara.dev/docs/contact). diff --git a/solara/website/pages/documentation/getting_started/content/07-deploying/10-self-hosted.md b/solara/website/pages/documentation/getting_started/content/07-deploying/10-self-hosted.md index ec2c600a6..9d83711a2 100644 --- a/solara/website/pages/documentation/getting_started/content/07-deploying/10-self-hosted.md +++ b/solara/website/pages/documentation/getting_started/content/07-deploying/10-self-hosted.md @@ -65,7 +65,7 @@ A typical command would be: $ SOLARA_APP=sol.py gunicorn --workers 4 --threads=20 -b 0.0.0.0:8765 solara.server.flask:app ``` -Note that we need at least 1 thread per user due to the use of a websocket. +Note that we need at least 1 thread per user due to the use of a websocket. *Make sure you understand the implications of using multiple workers by reading [about handling multiple workers with solara server](https://solara.dev/documentation/advanced/understanding/solara-server#handling-multiple-workers)* ### Embedding in an existing Flask application @@ -98,6 +98,8 @@ For [Starlette](https://www.starlette.io/) we will assume [uvicorn](http://www.u $ SOLARA_APP=sol.py uvicorn --workers 4 --host 0.0.0.0 --port 8765 solara.server.starlette:app ``` +*Make sure you understand the implications of using multiple workers by reading [about handling multiple workers with solara server](https://solara.dev/documentation/advanced/understanding/solara-server#handling-multiple-workers)* + ### Embedding in an existing Starlette application If you already have a Starlette app and want to add your Solara app behind a prefix, say `'/solara/'`, you can mount the Starlette routes for Solara to your existing app as follows.