Hi, IMHO, The multi process approach has to be preferred over multi-threading
Some thought about it: Forking sever instance for each request is imho a bad idea as it is not scalable and defeat resource control. I think that it is not a problem by itself to consider the server engine as single worker process: there is numerous cases where it is much better handled using appropriates tools: - Use supervisor with fcgi prefork to handle a pool of server (not sure is is appropriate here) - Embed the server in a asynchronous framework (like tornado, or python 3 asyncio) and use multiprocessing to handle your server workers. - Embed as wsgi application and use gunicorn mumérous options to handle requests queues and the number workers. … David. IMHO this can be handled in much better way with other tools: > Le 19 nov. 2017 à 10:34, Alessandro Pasotti <apaso...@gmail.com> a écrit : > > Hi, > > mi recent experiments with multi-threaded python wrappers for QGIS server > showed a critical flaw in my original implementation of the server plugins. > > First, I want to stress that this is not a problem in FCGI server > implementation but only if the server is used directly from python in a multi > threaded server implementation. > > The problem is that the server interface that exposes the request handler is > a static property of the interface, that is changed on every request. > This means that there is a race condition in setting/accessing the handler > from a plugin filter, and that a plugin filter might access to the handler > for a wrong request. > > The solution is to pass the request handler (or the request and/or response > objects depending on the filter) to the plugin filters and leave the > interface for static properties only. > > This would be a big API change for the server interface and filters and I'm > not sure we have time/resources to do that now. > > As an alternative we could simply document the issue and change the testing > code to create a new server instance to server every request (to be verified, > and with consitent performance degradation). > > What's your opinion about this issue? > > BTW, tomorrow I'll file a ticket for this problem. > > -- > Alessandro Pasotti > w3: www.itopen.it > <http://www.itopen.it/>_______________________________________________ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
