Show and Tell - brain-plasma (fast sharing for large objects between callbacks)

mwveliz · November 11, 2020, 5:39pm

Hi @dldx I am not sure because I only use one worker, but maybe this way (using --preload) you could do it:

gunicorn --preload src.app:server --bind 0.0.0.0:8000 --log-level=info --timeout=90

as descirbed on

github.com/plotly/dash

Flask route returns 403 due to CSRF failure when using multiple worker process

opened 05:56AM - 10 Sep 17 UTC

closed 03:33PM - 12 Sep 17 UTC

ned2

I've tried running a Dash app with multiple worker processes using both Gunicorn… and mod_wsgi-express and have found that this results in the `_dash-update-component` route responding with a 403 Bad Request response intermittently. After digging into it a bit I think what's happening is that the Dash app is loaded as a separate instance within each worker process, which results in a different CSRF secret key being generated for the SeaSurf middleware for each worker process, but the client only knows about one of them. So the app might work ok for a few requests, while worker with the right key happens to handle the requests, but as soon as a worker with a non-matching key is allocated to handle the request, we get this error: ``` -------------------------------------------------------------------------------- WARNING in flask_seasurf [[...]lib/python3.6/site-packages/flask_seasurf.py:282]: Forbidden (CSRF token missing or incorrect.): /_dash-update-component -------------------------------------------------------------------------------- ``` And indeed initialising the Dash app with `csrf_protect=False` makes this problem go away. I've found a simple workaround for this issue when using Gunicorn, which is to set the preload_app setting to True, which can be done by providing the --preload flag on the command line. eg: `gunicorn --preload --workers 2 --bind 0.0.0.0:5000 main:app.server` This has the effect of making Gunicorn load the app first before the worker process are forked, meaning they all share the same initialised state (and therefore the same secret key). This is also useful if your Dash app involves memory intensive objects, as you only need to store one copy in memory rather than n copies, where n is the number of workers. It could be worth finding a more general solution (I haven't looked into whether there's a similar preload setting for mod_wsgi), or maybe this this is an acceptable workaround, in which case perhaps this wants to be documented somewhere. I'd be happy to put together a Gunicorn section for the deployment page in the Dash User Guide.

and

Hope it can help you

Topic		Replies	Views
Show and tell: Super-fast way to share data between callbacks: Apache Plasma in-memory object store Dash Python show-and-tell	4	8428	May 9, 2019
Apache Arrow and Dash - Community Thread Dash Python	8	9157	September 15, 2020
Show and Tell - Community Thread :tada: Dash Python show-and-tell	87	48455	June 7, 2023
Show and Tell - WebDash (Dash running entirely in the browser) Dash Python show-and-tell	6	2460	May 25, 2021
Show and Tell - Making Interactive Machine Learning Explorers using Dash + Scikit-learn Dash Python show-and-tell	2	2266	August 9, 2018

Show and Tell - brain-plasma (fast sharing for large objects between callbacks)

Related topics