views:

1301

answers:

3

I am facing the dreaded "Unhandled Exception" raised by Flup. The sad part is its raised at the webserver (lighttpd+flup) level and not at the application level(Django). So no 500 email is raised about where the problem is.

Our entire team struggled hard to cleanup the codebase, incase of any ambigous imports and someones of that sort, just to be eliminate the chances of raising errors due to the ambiguous imports. And we cleaned up many things in the code. Still the same exception.

To be frank I am really frustrated with Flup's error handling. It doesn't tell you anything. Worst of all, it shows the same "Unhandled Exception" to the Users. How do I get pass this?

I checked the lighttpd logs. All I see is "Interface Error/Connection already closed." Its only occurring when my applicaiton is running in FCGI mode. So the problem is with how flup is actually dealing with my code(application). How do I get pass this?

I checked for alternatives for flup, but Django depends on flup explicitly(which is one more restriction, and puzzled me)(Reference:django_src/django/core/servers/fastcgi.py line:100 / 131)

How do I debug (atleast) this scenario and solve the problem? Please help me out. The application has been down for 3 days.

+2  A: 

I don't use lighttpd or flup, so this isn't an answer as much as it is hints.

I'd start by trying to run PDB in your app file, or at least writing to a logfile before you call the flup server .run() method. That way you can identify the problem as being in fastcgi or in flup. See the section called Python Interactive Debugger in the mod_wsgi wiki. That might give you ideas on how to do the same thing with lighttpd and flup.

Then, if the problem is flup you'll catch the exception in pdb and can debug from there.

If the problem is lighttpd then you probably have some kind of problem in your config file, or maybe a problem with the way lighttpd was built. Maybe there's a system library mismatch between lighttp and its fastcgi module?

Try running your app under nginx+fastcgi and see if that works or at least gives you better error messages.

Btw, the author of flup hates FCGI and doesn't even use flup anymore... I'd recommend switching to nginx or apache+mod_wsgi.

Van Gale
Thanks Van. I completely get it and presently I am interested in wsgi internals and reading about nginx. But. Whats your comment about django dependance on flup??(I have mentioned fastcgi.py in my question. Please have a look at it)
Maddy
To run Django with nginx you need to bridge WSGI to FastCGI - which is Flup's task actually.
zgoda
Maddy
@Maddy: Django depends on flup IF you need Django/FastCGI, which you do with nginx or lighttpd. If you run your Django site via Apache/mod_wsgi or Spawning, they support WSGI directly, so there is no need for FastCGI or flup. I recommend abandoning lighttpd, it has known memory leak problems.
Carl Meyer
You can also run your Django site via Apache/mod_wsgi or Spawning, and have a front-end nginx that serves static content and proxies dynamic requests back to your Django server. This is what I do.
Carl Meyer
For the record I'm doing this now as well... nginx front end passing requests to apache + mod_wsgi backend. The low resource usage is amazing and performance is excellent plus I can reverse proxy multiple SSL sites.
Van Gale
+3  A: 

This indicates error well before Django starts processing request, like syntax error within settings module. The fastest way to debug such problem is to turn on FastCGI debug. This is the line 128 in django/core/servers/fastcgi.py:

wsgi_opts['debug'] = False # Turn off flup tracebacks

Then run the app with such modified Django, You'll see the Flup traceback in whole its glory.

zgoda