> On 16 May 2016, at 9:49 PM, Rory Campbell-Lange <[email protected]>
> wrote:
>
> Dear All
>
> We have many separate copies of apps which need to run in separate
> TimeZones.
>
> I'd like to confirm that setting the TZ in the wsgi file for any app
> under a WSGIDaemon is the best way to do it. (I'm aware that different
> TZs under the same WSGIDaemon won't work). I was unable to correctly set
> the TZ in Apache.
Correct, you can't use SetEnv. That only populates the per request environment
with mod_wsgi and doesn’t set process environment variables.
> I'd also like to confirm that while setting the TZ is necessary under a
> WSGIDaemon, it is ok to run copies of the same app with the same TZ
> but different configuration under the same WSGIDaemon but with different
> WSGIApplicationGroup names. For instance, I might have 3 apps in the
> Australia/Sydney TZ which are collected under the same WSGIDaemon, but
> can each be configured to use different databases so long as they have
> different WSGIApplicationGroup names.
Although that technically can be done, I would still recommend a separate
mod_wsgi daemon process group per distinct hosted application.
This is so that you can always force:
WSGIApplicationGroup %{GLOBAL}
for all instances of the application.
Using this will force the use of the main interpreter context in the respective
mod_wsgi daemon process groups, which is equivalent to using command line
Python.
If you don’t do that and make use of sub interpreter support of Python, you do
run the risk of things not working if you have to use a Python package with a C
extension component that hasn’t been implemented properly to work correctly in
sub interpreters. Any C extension that uses the simplified Python API for
thread state management can be a problem, as that interface isn’t compatible
with sub interpreters.
http://modwsgi.readthedocs.io/en/develop/user-guides/application-issues.html#python-simplified-gil-state-api
You don’t really loose out by having them in separate mod_wsgi daemon process
groups and that can actually be better as it allows you then to control
processes/threads, timeouts etc for each as necessary and restart them
independently if necessary.
> When testing this setting the WSGIProcessGroup seemed to work under both
> a <Location> and <Directory> block, which the docs suggest shouldn't happen.
> http://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIProcessGroup.html
> Using <Location> is good for us due to the correlation with the url end
> point across hundreds of production apps.
There is no issue with using Location directive as the context for
WSGIProcessGroup. In saying a context of ‘directory’, that also means Location
directive.
The definition of what the values mean for context can be found in Apache
documentation at:
http://httpd.apache.org/docs/2.4/mod/directive-dict.html#Context
<http://httpd.apache.org/docs/2.4/mod/directive-dict.html#Context>
Graham
> Please refer to the test setup below, together with the results at the
> bottom.
>
> Regards
> Rory
>
>
> Flask app:
>
> from flask import Flask
> app = Flask(__name__)
>
> from datetime import datetime
> import os
>
> @app.route('/')
> def main():
> now = datetime.now()
> tz = os.environ.get('TZ', 'not set')
> rstr = r'''The time is presently %s <br />TZ is %s''' % (now, tz)
> return rstr
>
> if __name__ == '__main__':
> app.run()
>
> wsgi configs:
>
> appa:
> import sys
> import os
>
> os.environ['TZ'] = 'Australia/Sydney'
> sys.path.append('/var/www')
> from flasket.test import app as application
>
> appb:
> import sys
> import os
>
> os.environ['TZ'] = 'Europe/London'
> sys.path.append('/var/www')
> from flasket.test import app as application
>
> appc:
> import sys
> import os
>
> os.environ['TZ'] = 'America/Whitehorse'
> sys.path.append('/var/www')
> from flasket.test import app as application
>
> appd:
> import sys
> import os
>
> # os.environ['TZ'] = inherit from appa TZ?
> sys.path.append('/var/www')
> from flasket.test import app as application
>
> apache daemon configs (in /etc/apache2/wsgi_daemons):
> a:
> WSGIDaemonProcess app_a threads=2 inactivity-timeout=600
> b:
> WSGIDaemonProcess app_b threads=2 inactivity-timeout=600
> c:
> WSGIDaemonProcess app_c threads=2 inactivity-timeout=600
> d (not used)
>
> apache config:
>
> <VirtualHost *:80>
>
> ServerAdmin webmaster@localhost
> DocumentRoot /var/www/html
>
> ErrorLog ${APACHE_LOG_DIR}/error.log
> CustomLog ${APACHE_LOG_DIR}/access.log combined
>
> WSGIScriptAlias /a /var/www/appa/a.wsgi
> <Directory /var/www/appa>
> WSGIProcessGroup app_a
> WSGIApplicationGroup app_a
> Order deny,allow
> Allow from all
> </Directory>
>
> WSGIScriptAlias /b /var/www/appb/b.wsgi
> <Directory /var/www/appb>
> WSGIProcessGroup app_b
> WSGIApplicationGroup app_b
> Order deny,allow
> Allow from all
> </Directory>
>
> WSGIScriptAlias /c /var/www/appc/c.wsgi
> <Location /c>
> WSGIProcessGroup app_c
> WSGIApplicationGroup app_c
> # SetEnv TZ America/Whitehorse # doesnt work
> Order deny,allow
> Allow from all
> </Location>
>
> WSGIScriptAlias /d /var/www/appd/d.wsgi
> <Location /d>
> WSGIProcessGroup app_a # use wsgi daemon a
> WSGIApplicationGroup app_d
> Order deny,allow
> Allow from all
> </Location>
>
> </VirtualHost>
>
> output (note my machine TZ is Europe/London):
> curl 127.0.0.1/a:
> The time is presently 2016-05-16 21:36:57.989711 <br />TZ is
> Australia/Sydney
>
> curl 127.0.0.1/b:
> The time is presently 2016-05-16 12:38:09.895517 <br />TZ is
> Europe/London
>
> curl 127.0.0.1/c (Location):
> The time is presently 2016-05-16 04:38:32.401697 <br />TZ is
> America/Whitehorse
>
> curl 127.0.0.1/d (Location, using WSGIDaemonProcess 'a'):
> The time is presently 2016-05-16 21:39:21.669184 <br />TZ is
> Australia/Sydney
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at https://groups.google.com/group/modwsgi.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
