On 31 May 2012, at 08:23, Evgeny Turnaev wrote: > Hello. > Why dont you just include java thread local data in every wsgi > request so that wsgi server wont need to make rpc call? > Architecture where backend should ask frontend back (especially > same thread) before replying original request looks vary bad imo.
Thank you for your feedback. I cannot include java thread local data into the wsgi request (not all of it, anyways) because it can include java objects that cannot or should not be serialized, and because I wouldn't know what to to with those Java objects in Python, they must be processed inside the JVM. In this scenario Java and Python are cooperating. I want to offload (some) http requests to Python, so that I can develop the web application with Django, but I must still be able to make Java calls inside my web application, and reuse existing Java libraries. My first version ran entirely inside Java, using Jython for the Python code. But Jython has such bad performance and memory leaks that it's not a realistic option. Also, I want to be able to change / reload the Python code without restarting the entire Java behemoth :-) Yes, I could put references to java thread locals into a global java dictionary, indexed by thread id, at the start of every request, and then Python would issue "clean" RPCs back to the JVM that get executed on another thread, and fetch the original locals from the dictionary, and then make sure to get all the Java synchronization and cleanup code right. But it seems more complicated (and thus slow) than just using a custom protocol between java and python: -> wsgi request, (<- rpc request, -> rpc response)*, <- wsgi response. The reason for "extending" the uWSGI protocol, instead of writing one from scratch, is so that I don't have to rewrite an entire Python application server, with process management and everything else. Tobia _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
