<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi,<br class=""><div class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">IMHO, The multi process approach has to be preferred over multi-threading</div><div class=""><br class=""></div><div class="">Some thought about it:</div><div class=""><br class=""></div><div class="">Forking sever instance for each request is imho a bad idea as it is not scalable and defeat resource control.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">- Use supervisor with fcgi prefork to handle a pool of server (not sure is is appropriate here)</div><div class="">- Embed the server in a asynchronous framework (like tornado, or python 3 asyncio) and use multiprocessing to handle your server workers.</div><div class="">- Embed as wsgi application and use gunicorn mumérous options to handle requests queues and the number workers.</div><div class="">…</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">David. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">IMHO this can be handled in much better way with other tools:</div><div class=""><br class=""></div></div></div><div><blockquote type="cite" class=""><div class="">Le 19 nov. 2017 à 10:34, Alessandro Pasotti <<a href="mailto:apasotti@gmail.com" class="">apasotti@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class="">Hi,<br class=""><br class=""></div>mi recent experiments with multi-threaded python wrappers for QGIS server showed a critical flaw in my original implementation of the server plugins.</div><div class=""><br class=""></div><div class="">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.<br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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).<br class=""></div><div class=""><br class=""></div><div class="">What's your opinion about this issue?</div><div class=""><br class=""></div><div class="">BTW, tomorrow I'll file a ticket for this problem.<br class=""></div><div class=""><div class=""><div class=""><div class=""><br class="">-- <br class=""><div class="gmail_signature">Alessandro Pasotti<br class="">w3: <a href="http://www.itopen.it/" target="_blank" class="">www.itopen.it</a></div>
</div></div></div></div></div>
_______________________________________________<br class="">QGIS-Developer mailing list<br class=""><a href="mailto:QGIS-Developer@lists.osgeo.org" class="">QGIS-Developer@lists.osgeo.org</a><br class="">List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer<br class="">Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer</div></blockquote></div><br class=""></body></html>