Hi Johannes, On 10/10/2015 08:24 AM, Johannes Bauer wrote: > I'm running an Apache 2.4 webserver using mod_wsgi 4.3.0. There are two > different applications running in there running on two completely > separate vhosts. > > I'm seeing some weird crosstalk between them which I do not understand. > In particular, crosstalk concerning the locales of the two. One > application needs to output, e.g., date information using a German > locale. It uses locale.setlocale to set its LC_ALL to de_DE.UTF-8. > > Now the second application doesn't need nor want to be German. It wants > to see the C locale everywhere, in particular because at some point it > uses datetime.datetime.strptime() to parse a datetime. > > Here's where things get weird: Sometimes, my "C" locale process throws > exceptions, because it's unable to parse a date. When looking why this > fails, the string looks like de_DE's "Sa, 10 Okt 2015" instead of C's > "Sat, 10 Oct 2015". This seems to happen depending on which worker > thread is currently serving the request, i.e. nondeterministically. > > So all in all, this is very weird and I must admit that I don't seem to > fully understand how WSGI applications are run and served within a > mod_wsgi framework altogether. In the past it all "just worked" and I > didn't need to understand it all in-depth. But I think to be able to > debug such a weird issue, in-depth knowledge of what happens under the > hood would be helpful. > > So if someone could shed some light on how it works in general or what > could cause the described issue in particular, I'd really be grateful.
It's been a number of years since I used mod-wsgi (I prefer gunicorn or uwsgi, in part because I find their process model so much easier to understand), but as best I understand (hopefully if I get anything wrong, someone who knows better can correct me) mod-wsgi uses a little-known CPython feature called "sub-interpreters", meaning that even multiple mod-wsgi sites on the same server can run in sub-interpreters of the same Python process, and certain global state (e.g. os.environ, apparently also the localization context) is shared between those sub-interpreters, which can cause "crosstalk" issues like you're seeing. I'm not sure, but I think _maybe_ using WSGIDaemonProcess [1] and putting your sites in different WSGIProcessGroup [2] might help? Carl [1] https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess [2] https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess
signature.asc
Description: OpenPGP digital signature
-- https://mail.python.org/mailman/listinfo/python-list