> On 28 Jul 2017, at 1:50 AM, Scott D Anderson <[email protected]>
> wrote:
>
> That worked perfectly, Graham. Thank you!
>
> I read the documentation on WSGIApplicationGroup, and I'm afraid I didn't
> completely understand it. Is there any downside to using %{GLOBAL} routinely
> instead of the default?
When hosting multiple applications (or even one), is always recommended that
each WSGI application is delegated to its own daemon process group and for the
main interpreter to be used by setting the WSGIApplicationGroup directive in
that way, or by using application-group option to WSGIScriptAlias.
> I don't have a lot of applications running on this server. My "production"
> application, which is the only one I care about, is defined thus:
>
> WSGIApplicationGroup %{GLOBAL}
> WSGIDaemonProcess md user=scott processes=1 threads=8 display-name=apache2-md
> home=/var/www/html/scott/prod
>
You may not want to set 'processes=1'. One process is the default anyway, and
explicitly setting it has a side effect of causing wsgi.multiprocess to be set
to True in the WSGI environ dictionary. It is unlikely that will matter though.
This strange side affect is a way of flagging a multiprocess configuration even
if one process, for when running multiple instances of single process
application on different hosts/containers and load balancing across them.
> WSGIScriptAlias /scott/prod/md /var/www/html/scott/prod/md.wsgi
> process-group=md
>
You could instead also add application-group option here instead of using
WSGIApplicationGroup.
Just be aware that setting both application-group and process-group at same
time on WSGIScriptAlias has a side effect of enabling preloading of the WSGI
script file on process startup, rather than lazily on first request.
> So, this is using daemon mode, right? It didn't work before I set
> WSGIApplicationGroup to %{GLOBAL}, but it does now. Is there any flaw with
> this combination of settings?
Nothing wrong. Some suggestions above though.
> Thanks again,
>
> Scott
>
>
> On Wed, Jul 26, 2017 at 5:15 PM, Graham Dumpleton <[email protected]
> <mailto:[email protected]>> wrote:
> The numpy package can fail when used in Python sub interpreters.
>
> Preferably use daemon mode, but more importantly delegate the WSGI
> application to run in the main interpreter context by setting
> WSGIApplicationGroup.
>
>
> http://modwsgi.readthedocs.io/en/develop/user-guides/application-issues.html#python-simplified-gil-state-api
>
> <http://modwsgi.readthedocs.io/en/develop/user-guides/application-issues.html#python-simplified-gil-state-api>
>
> See if that changes anything.
>
> If not, next issue would be to make sure lang/locale is set to reasonable
> value.
>
> Graham
>
>> On 27 Jul 2017, at 4:36 AM, Scott D Anderson <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> This might be the wrong venue for this question, but WSGI is part of the
>> trouble, and Graham is always so helpful and responsive that it seems best
>> to start here.
>>
>> I ran into a difficult-to-debug error in a Flask application, which I
>> eventually boiled down to a very short example. I'll give the complete
>> implementation with logs below, but let me start at the high level:
>>
>> The high-level description is pretty simple: there's a data structure that
>> I had a "print" statement for. The print statement works perfectly in the
>> development version, but when I run the code in a "production" WSGI
>> environment, the print statement causes the server process to hang, with a
>> "500 Internal Server Error" in the browser. So, somehow, printing is
>> fundamentally different between development and WSGI, so I thought to start
>> here.
>>
>> Here's the complete code for the application:
>>
>> from flask import Flask
>>
>> import pandas
>> import numpy
>>
>> application = Flask(__name__)
>>
>> @application.route('/')
>> def index():
>> print('about to load JSON')
>> df = pandas.read_json('/var/www/html/scott/prod/dfbad.json')
>> print('JSON loaded')
>> print('df is ',df)
>> return '<!doctype html><html><body>df is '+str(df)+'</body></html>'
>>
>>
>> if __name__ == '__main__':
>> port = 5000
>> application.run('0.0.0.0',port=port)
>>
>> In development mode, the (slightly edited) console output looks like this:
>>
>> about to load JSON
>> JSON loaded
>> ('df is ', basal_amt bolus_volume carbs date_time rec_num
>> 0 0.375 NaN NaN 2016-04-03 18:31:00 18539
>> 1 0.000 NaN NaN 2016-04-03 18:37:00 18540
>> ...
>> 7 1.100 NaN NaN 2016-04-03 20:31:00 18546
>> 8 0.000 NaN NaN 2016-04-03 21:13:00 18547
>> 9 1.100 NaN NaN 2016-04-03 21:16:00 18548)
>> 127.0.0.1 - - [26/Jul/2017 10:47:05] "GET / HTTP/1.1" 200 -
>>
>> The GET response looks like this:
>>
>> GET http://localhost:5000/ <http://localhost:5000/>
>> <!doctype html><html><body>df is basal_amt bolus_volume carbs
>> date_time rec_num
>> 0 0.375 NaN NaN 2016-04-03 18:31:00 18539
>> 1 0.000 NaN NaN 2016-04-03 18:37:00 18540
>> ...
>> 7 1.100 NaN NaN 2016-04-03 20:31:00 18546
>> 8 0.000 NaN NaN 2016-04-03 21:13:00 18547
>> 9 1.100 NaN NaN 2016-04-03 21:16:00 18548</body></html>
>>
>> However, if I set up a WSGI production version (apache2, version
>> 2.4.18-2ubuntu3.3) like this:
>>
>> WSGIScriptAlias /df_not_printable
>> /var/www/html/scott/prod/df_not_printable.py
>>
>> Then the response to the GET request is the following:
>>
>> GET http://localhost/df_not_printable <http://localhost/df_not_printable>
>> read timeout at /usr/share/perl5/Net/HTTP/Methods.pm line 273, <STDIN> line
>> 2.
>>
>> The /var/log/apache2/error.log shows the following:
>>
>> [Wed Jul 26 10:48:09.164138 2017] [wsgi:info] [pid 2291] mod_wsgi
>> (pid=2291): Create interpreter 'ip-132-148-72-77.ip.secureserver.net
>> <http://ip-132-148-72-77.ip.secureserver.net/>|/df_not_printable'.
>> [Wed Jul 26 10:48:09.165605 2017] [wsgi:info] [pid 2291] [client
>> 127.0.0.1:48072 <http://127.0.0.1:48072/>] mod_wsgi (pid=2291, process='',
>> application='ip-132-148-72-77.ip.secureserver.net
>> <http://ip-132-148-72-77.ip.secureserver.net/>|/df_not_printable'): Loading
>> WSGI script '/var/www/html/scott/prod/df_not_printable.py'.
>> [Wed Jul 26 10:48:09.658077 2017] [wsgi:error] [pid 2291] about to load JSON
>> [Wed Jul 26 10:48:09.701097 2017] [wsgi:error] [pid 2291] JSON loaded
>>
>> So, you can see that the first two 'print' statements worked fine and went
>> to the log, but trying to print this pandas dataframe caused a catastrophe.
>> There is nothing more in the logs; that's the last line. There's no stack
>> backtrace, no exception, no hint about what could possibly have gone wrong.
>> Maybe some kind of infinite loop?
>>
>> I know it's tempting just to blame pandas for the trouble, but I haven't a
>> clue about what went wrong or how to debug this. Obviously, for now I'll
>> just avoid printing any dataframes, but I worry about other unprintable
>> objects out there.
>>
>> Thanks,
>>
>> Scott
>> --
>> Scott D. Anderson
>> Computer Science Department
>> Wellesley College
>> [email protected] <mailto:[email protected]>
>> [email protected] <mailto:[email protected]>
>> pronouns: he, him, his
>>
>>
>>
>> --
>> 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]
>> <mailto:[email protected]>.
>> To post to this group, send email to [email protected]
>> <mailto:[email protected]>.
>> Visit this group at https://groups.google.com/group/modwsgi
>> <https://groups.google.com/group/modwsgi>.
>> For more options, visit https://groups.google.com/d/optout
>> <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]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> Visit this group at https://groups.google.com/group/modwsgi
> <https://groups.google.com/group/modwsgi>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
>
> --
> Scott D. Anderson
> Computer Science Department
> Wellesley College
> [email protected] <mailto:[email protected]>
> [email protected] <mailto:[email protected]>
> pronouns: he, him, his
>
>
>
> --
> 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]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> Visit this group at https://groups.google.com/group/modwsgi
> <https://groups.google.com/group/modwsgi>.
> For more options, visit https://groups.google.com/d/optout
> <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.
