Re: Understanding WSGI together with Apache
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
Re: Understanding WSGI together with Apache
Johannes Bauer wrote: > 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. There is a library that might interest you. Babel allows multiple locales in the same process. See http://babel.pocoo.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Understanding WSGI together with Apache
Johannes Bauer writes: > 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. This is more an Apache than a Python question. The "locale" implementation does not expect different "locale"s in the same process (this is true not only on the Python but also on the "C" level). Thus, if in a single process, two concurrent activities (i.e. threads) need different "locale"s, you are in trouble. Your problem discription indicates that something like this is happening in your WSGI setup. I suppose that a single Python process is not used to process several requests at the same time (but I may be wrong). In this case, you have a chance to set the correct locale for the current request processing at request start. If, however, a single Python process is used for all requests and concurrent requests are handled by separate tasks, then there is no safe way to get the "locale" right. At your place, I would search the Apache documentation related to "mod_wsgi" to find out how it uses processes and tasks for request processing. -- https://mail.python.org/mailman/listinfo/python-list
