On 7/10/15 11:16 AM, Barry Warsaw wrote:
On Jul 10, 2015, at 10:43 AM, Barry Warsaw wrote:
My thinking is that a gunicorn -or other external wsgi server- based REST runner wouldn't do much more than run gunicorn with the proper commands in a subprocess, and manage its PID so that the runner itself could response to
mailman stopandrestartcommands.I took a slightly different approach. Basically don't start gunicorn with
mailman startbut start it in a shell after the main system is up and running. Here's a very experimental and almost completely untested branch that could get you started:https://gitlab.com/warsaw/mailman/tree/gunicorn
Read the docstring in this commit for details.
https://gitlab.com/warsaw/mailman/commit/3fbfde8793c9c5bf12b0f250a58b3e3134f...
This didn't work for me without modification, both because gunicorn was trying to pass 2 arguments into make_application, and because the initialization was trying to happen each request, which caused issues (mailman crashing trying to add the same language twice).
Here's how I resolved it (API running under gunicorn 19.3.0 correctly responds to requests; didn't test much beyond that):
https://gitlab.com/emsearcy/mailman/commit/33fa949cfa190d32e3fd68ed02e787cc0...
It's curious to me that Mailman Bundler makes references to Gunicorn support, but it seems there code would run into the same problems I did (multiple initiations and argument count mismatch). Is anybody using this from Bundler currently and can help me figure out why the difference?
https://mailman-bundler.readthedocs.org/en/latest/ https://gitlab.com/mailman/mailman-bundler/blob/master/mailman_web/wsgi.py https://gitlab.com/mailman/mailman-bundler/blob/master/templates/deployment/...
Best regards,
Eric