-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
BUG: WSGI incompatibility, destroying downstream A.I. web apps based on Torch, TensorFlow, Jax, ... #26039
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
Comments
dupe of #24755, the main reason this hasn’t been done is it’s an enormous amount of work (at a minimum, a large scale refactor of numpy’s C code from static python types to heap types). |
Given that there is not sufficient interest and resources to resolve this “the right way”, how might you recommend one proceeds to be able to effectively incorporate NumPy et al. in a web serving environment based on Apache etc.? I’m not looking for anything fancy or special, just the most sensible basic workaround. I ask because maybe this is more obvious to you and mentioning notes here could potentially help others. A few starting thoughts / hypotheses:
“Simplicity is ultimate sophistication”, let me know if any ideas come to mind. |
The standard solution is to use Gunicorn/Uvicorn just behind your Apache/nginx frontend to manage the numpy-using worker processes. |
Thank you! |
Finally implemented this change, happy to say "it works!". |
I'm having the same problem. How did you solve it? Thanks |
Describe the issue:
WSGI and NumPy are not friends. Someone who understands both libraries should consider helping out what is probably hundreds to thousands of A.I. developers who'd love to deploy a standard Apache server with standard A.I. tools...
Reproduce the code example:
Error message:
[Fri Mar 15 17:54:35.669711 2024] [wsgi:error] [pid 896464:tid 140159483893312] /var/www/ecodash/venv/lib/python3.10/site-packages/pandas/__init__.py:14: UserWarning: NumPy was imported from a Python sub-interpreter but NumPy does not properly support sub-interpreters. This will likely work for most users but might cause hard to track down issues or subtle bugs. A common user of the rare sub-interpreter feature is wsgi which also allows single-interpreter mode.
The text was updated successfully, but these errors were encountered: