Where are my 500s coming from in my DJango app? - django

Question

I've got Apache setup on windows, (yes, not a very good idea, but not my fault). I open a popup window with about 32 images in it and all but 3 of those image links work. The images are coming from a TIF file and therefore have to be converted, so it is running thru my Django app to do all this and that part is working. The 3 urls that fail, when retried work.
In the apache log, I get 29 200s followed by 3 500s, but the actual images that failed to load are scattered randomly among the 29 good images. When I watch the log with tail -f, the 500s come along many seconds after the 200s but timestamped BEFORE them, like so:
192.168.20.45 - - [08/Mar/2012:01:24:28 -0600] "GET /viewer/... 200 44277
192.168.20.45 - - [08/Mar/2012:01:24:28 -0600] "GET /viewer/... 200 52283
192.168.20.45 - - [08/Mar/2012:01:24:28 -0600] "GET /viewer/... 200 44991
192.168.20.45 - - [08/Mar/2012:01:24:29 -0600] "GET /viewer/... 200 33077
192.168.20.45 - - [08/Mar/2012:01:24:22 -0600] "GET /viewer/... 500 16
192.168.20.45 - - [08/Mar/2012:01:24:22 -0600] "GET /viewer/... 500 16
192.168.20.45 - - [08/Mar/2012:01:24:22 -0600] "GET /viewer/... 500 16
DEBUG=False, and admins are setup, so I should get an email for every 500 that happens in Django, I've tested the email and it works as expected. The code I'm going thru has logging statements for error conditions and none of those are triggering.
It's almost like Apache or Mod_wsgi knows these connections come in, but never passes them to the Django code and they just end up dying from what seems to be a timeout. Chrome DevTools ends up showing me:
**Response Headers**
Connection:close
Content-Type:text/html; charset=utf-8
Date:Thu, 08 Mar 2012 07:24:22 GMT
Server:Apache/2.2.21 (Win32) mod_wsgi/3.3 Python/2.7.2
Set-Cookie:sessionid=d4616w0f850u1eb33q7a6fzf37f840b5; Path=/
Transfer-Encoding:chunked
Vary:Cookie
I'm on windows, and Apache says this on startup:
[Thu Mar 08 01:38:09 2012] [warn] mod_wsgi: Compiled for Python/2.7.
[Thu Mar 08 01:38:09 2012] [warn] mod_wsgi: Runtime using Python/2.7.2.
[Thu Mar 08 01:38:09 2012] [notice] Apache/2.2.21 (Win32) mod_wsgi/3.3 Python/2.7.2 configured -- resuming normal operations
[Thu Mar 08 01:38:09 2012] [notice] Server built: Sep 9 2011 10:26:10
[Thu Mar 08 01:38:09 2012] [notice] Parent: Created child process 3260
[Thu Mar 08 01:38:09 2012] [warn] mod_wsgi: Compiled for Python/2.7.
[Thu Mar 08 01:38:09 2012] [warn] mod_wsgi: Runtime using Python/2.7.2.
[Thu Mar 08 01:38:09 2012] [notice] Child 3260: Child process is running
[Thu Mar 08 01:38:09 2012] [notice] Child 3260: Acquired the start mutex.
[Thu Mar 08 01:38:09 2012] [notice] Child 3260: Starting 64 worker threads.
[Thu Mar 08 01:38:09 2012] [notice] Child 3260: Starting thread to listen on port 80.
There are less than 64 requests so there should be threads left over to handle them.
Any ideas on WHAT is happening? or HOW to figure it out?
EDIT----
There is no traceback, that is the problem. There is no indication at all that Python ever saw this request.
Yes, you shouldn't use python to serve static files, but you can't put a single image TIFF from a multi image TIFF into an you have to pull it from the multi-image file, put it in a format the browser can display, and no you don't want to convert the 100+ million TIFF images into single image PNGs or JPEG. AND these are not images that can be viewed by the general public, but are restricted to their "owners"
Loaded this on a second machine and the problem does not happen.....

Answer 1

You can write a small middleware to handle the exception. You can do some logging in the process_exception method, to find the root of the problem:
https://docs.djangoproject.com/en/dev/topics/http/middleware/#process-exception