On 15 February 2011 23:52, Josh Stratton <[email protected]> wrote:
> One issue I'm seeing is that my app might not be setup with mod_wsgi
> correctly as I see the main function called on every browser request.
That could only be if process is crashing. Look in main Apache error
log for 'Segmentation fault' messages.
Also modify LogLevel directive in Apache and set it to:
LogLevel info
This will cause mod_wsgi to output messages about daemon process
start/stop and WSGI script loading so you can see more about when
stuff happening.
> in my site-enabled file...
>
> WSGIDaemonProcess app processes=2 maximum-requests=500 threads=1
Don't use 'maximum-requests' unless you have a good reason to. Should
never be used in a production site if you can avoid it.
Also initially suggest you use:
WSGIDaemonProcess app threads=1
Ie., a single process with a single thread. This will ensure requests
go back to same process and that it isn't due to multiprocess nature
of the configuration.
> WSGIProcessGroup app
> WSGIScriptAlias /myapp /var/www/cgi-bin/test.py
>
> I believe the reason that the original web.py openid lib is failing is
> it's restarting every time. Even if mod_wsgi is working correctly,
> will using the library fail if it's running on multiple processes
> since user requests might not hit the same instance consecutively? I
> see there are apache processes being created as I increase the proces
> to the daemon process, but should that still cause my test.py app to
> start every frame?
>
> Here's the end of web.py app.
>
> app = web.application(urls, globals(), autoreload=False)
> application = app.wsgifunc()
>
> if __name__ == "__main__":
> error("starting main")
> app.run()
The 'if' is redundant as only applies to when script run on command
line. Comment it out and see if script still works. If it doesn't then
you may actually be running your script as CGI through missing
configuration, although that would be dependent on app.run() running
it as a CGI script as opposed to a standalone server.
Graham
> On Mon, Feb 14, 2011 at 7:12 PM, Josh Stratton <[email protected]>
> wrote:
>> Thanks, Graham. I'm kind of invested in web.py for this project, but
>> may check flask out for future projects or refactorings. I decided
>> that mod_auth_openid should fit my needs for now.
>>
>> On Mon, Feb 14, 2011 at 7:08 PM, Graham Dumpleton
>> <[email protected]> wrote:
>>> On 15 February 2011 00:05, strattonbrazil <[email protected]> wrote:
>>>> I modified the web.py library to write to an absolute path in /tmp instead,
>>>> and still didn't see any file being created, so I feel like something is
>>>> failing before that like a concurrency issue. Are there any openid
>>>> libraries I could use in the mean time that have worked well with mod_wsgi
>>>> in the past?
>>>
>>> Since web.py is somewhat dated, you may be better off using a more
>>> modern framework such as Flask. For Flask there is available
>>> Flask-OpenID. See:
>>>
>>> http://packages.python.org/Flask-OpenID/
>>>
>>> Otherwise you should hassle web.py maintainers.
>>>
>>> Graham
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "modwsgi" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected].
>>> For more options, visit this group at
>>> http://groups.google.com/group/modwsgi?hl=en.
>>>
>>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/modwsgi?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en.
