What are using to generate the images, a C extension module for Python?
Could be that you are encountering thread dead locks if code running
in Python sub interpreter.
If the only Python web application on host, try setting:
WSGIApplicationGroup %{GLOBAL}
Graham
On 15 August 2011 12:54, ellonweb <[email protected]> wrote:
> Hi Graham,
> Sorry to bring this back up; in my move from working prototype to
> actual implementation I have hit an error that is causing the Apache
> process to lock up and max out my CPU with no errors in the error log.
>
> The code works fine in the Django dev server, correctly generating PNG
> graphs and writing them to the filesystem for caching. Without the
> config you helped me with, Apache is able to do the same. With the
> extra config added in, Apache is able to correctly show the graphs
> already stored on the filesystem. However, with this extra config,
> when a graph is requested that isn't already generated, Apache locks
> up. After I kill the process the file is still written to the
> filesystem and loads correctly in my browser. It appears to work
> occasionally but I can't narrow it down, the same graphs will cause
> Apache to lock up sometimes and not others (I'm deleting the cached
> graphs and then refreshing).
>
> I'm not really sure how to start debugging this, your help would be
> much appreciated.
>
> Versions: Apache 2.2.17, mod_wsgi 3.3 (compiled for Py2.6.2), Py 2.6.6
> Commit of my code, which I can appreciate you probably don't want to
> spend time trawling through but the commit is pretty much limited to
> just my implementations of the things we discussed previously:
> https://github.com/ellonweb/merlin/commit/8aa87683c1766e6d4f173255162cc681fbdd69f9
>
> Please let me know how I should proceed or what further information is
> needed,
> Thanks in advance,
>
> On Jul 19, 5:13 am, Graham Dumpleton <[email protected]>
> wrote:
>> Sorry for taking so long to reply, work is sucking up my free time as
>> well at the moment.
>>
>> The issue you are seeing may well relate to this bug in Django.
>>
>> https://code.djangoproject.com/ticket/12464#comment:14
>>
>> Unfortunately a few days ago they marked it as closed as they can't
>> see that Django is doing the wrong thing. It isn't helped though by
>> fact that it isn't a simple thing to fix.
>>
>> What you may be able to do is use a special WSGI middleware wrapper
>> that adjusts the WSGI environ dictionary values as they get passed
>> through for the error document redirect, perhaps moving REDIRECT_URL
>> out of the way so that Django doesn't muck things up by trying to use
>> it, or otherwise modifying SCRIPT_NAME/PATH_INFO to values that make
>> things do what is necessary.
>>
>> Graham
>>
>> On 16 July 2011 03:16, ellonweb <[email protected]> wrote:
>>
>>
>>
>>
>>
>>
>>
>> > Thanks, this works very well; for reference, I'm able to get the
>> > original request url using REDIRECT_URL (which is accessible in
>> > django's request.META dict)
>>
>> > I still have one problem though in detecting the 404 url in the WSGI
>> > app (I'm using the same WSGI for multiple things, same environment
>> > etc), as it seems to vary in a peculiar manner:
>> > With "ErrorDocument 404 /handle_404", if my original request is /
>> > graphs/123, the reported path is /handle_404. /graphs/1234 gives //
>> > handler_404, /graphs/12345 gives /g/handler_404, ... /graphs/
>> > 1234567890 gives /graphs/handler_404, and with more characters I start
>> > to get the 1234.. coming through as well! It seems that "/handler_404"
>> > just replaces the last 11 characters of the request. I realize that
>> > this is probably getting a bit out of the mod_wsgi territory, but any
>> > ideas how to solve this? Or suggestions to detect the 404 url
>> > differently? I know an obvious solution is to use a seperate wsgi app
>> > but it's useful to keep the code/environment combined. (Also, maybe
>> > this is actually just a bug in django's handling?)
>>
>> > Many thanks,
>>
>> > On Jul 15, 2:21 am, Graham Dumpleton <[email protected]>
>> > wrote:
>> >> Have you tried something like:
>>
>> >> Alias /images/ /some/path/images/
>>
>> >> <Directory /some/path/images>
>> >> ErrorDocument 404 /handle_404
>> >> </Directory>
>>
>> >> WSGIScriptAlias /handle_404 /some/path/scripts/handle_404.wsgi
>>
>> >> You will need to pick through the WSGI request environment to see
>> >> whether the target file for the original request is included. I can't
>> >> remember exactly if it is.
>>
>> >> The WSGI script can then generate the file to temporary location and
>> >> then when done move it into correct place and return it for that
>> >> request as response from the WSGI script application.
>>
>> >> Graham
>>
>> >> On 13 July 2011 14:58, ellonweb <[email protected]> wrote:
>>
>> >> > Hi,
>>
>> >> > I've got a WSGIScriptAlias set up in Apache, and I'm adding some new
>> >> > functionality at /graphs/ that generate some PNG graphs for my
>> >> > website. I want to set up a caching system for these graphs, however,
>> >> > rather than having to go all the way through WSGI/Python etc. to read
>> >> > the previously generated images, is there a way to configure Apache to
>> >> > look for a file matching the url in some location (for example I use
>> >> > some static images using a normal Alias), and if the files don't
>> >> > exist, have Apache fall back to the WSGI which will generate and
>> >> > output the PNG (and then save it to the file system for future
>> >> > requests that can be served directly by Apache)? Perhaps using the
>> >> > WSGI as a 404 handler?
>>
>> >> > Thanks in advance,
>>
>> >> > --
>> >> > 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
>> >> > athttp://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
>> > athttp://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.
