[Web-SIG] Preferred set of WSGI servers

[Jacob Smullyan]

On Thu, Apr 28, 2005 at 01:02:31PM -0500, Ian Bicking wrote:
> For the forking server, I really have no idea.  There's several out
> there, but I don't know about all the features that are desirable or
> implemented.  Several of the servers don't speak HTTP.  I can't make
> any specific criticisms, because I don't even know what to look at.

I noticed that Alan Saddi has a adaptive preforking server
implementation in flup; it looks good.  SkunkWeb's preforking server,
which I am beginning to play with in the to-be-wsgi skunk4 branch,
isn't adaptive (by choice); it might become non-adaptive by default
but capable of being configured to be adaptive.  (For an app server
where you may have relatively heavy processes and be hanging on to
database connections in every connection, forking new processes as a
function of load can make a bad problem worse.)  My skunk4 sandbox in
skunkweb subversion has the base server modules, but no wsgi
integration yet; I'm distracted with other projects at the moment, but
I'll be cycling back to skunk4 soon, and will make a point of writing
a server compatible with paste.

> Lingering in the background of these server discussions are issues
> like user isolation and module reloading (and/or server restarting).

I don't see how single-process wsgi servers could provide user
isolation, if I understand you aright, except by proxying to other
processes, but a sort of suexec could conceivably be implemented even
as a middleware, if anyone feels like impaling themselves on that
project and being blamed for every resulting problem.  

As for reload/restart, are there any mysterious issues here? Are you
concerned about the implementation problem of getting reloading to
work, possibly at times other than at restart as well as at restart,
without broken references dangling, or the policy issue of how to try
to standardize restart behaviors for the different servers with Paste
(namely, how do they react to HUP, and if they restart, what do they
do to sys.modules), or something else?

Your clever reloader module seems to address the problem of reloading
for development convenience; I suppose it might occasionally break
things, but it's voluntary.  I do think it would be desirable to have
more or less the same signal handling for all the backends, although
this may not be the most exciting thing to work on right now; a
generic /etc/init.d/paste script shouldn't have to care which backend
you are calling, it should just know that it has a pid file it can do
the standard things to.   

Some refactoring ideas about the server layer occurred to me that
might be applicable in future and make things a bit more robust:

  1. The assumption (am I right it that there is one?) that
     servers only serve one port at a time should probably be 
     loosened at some point.  
  2. Support for running on UNIX sockets and privileged TCP
     ports (hence, dropping privileges) would also be a boon.  
  3. It would be cleaner and provide more options if the server
     process model and the particular lingo the server might talk 
     over a particular socket (http, scgi, fcgi, mod_skunk, etc.)
     were separated.  My approach would be to nest wsgi apps into 
     generic jobs of speaking a lingo, and associate each lingo-job 
     with a list of socket addresses; that addresses the first point,
     too.

Cheers,

js

-- 
Jacob Smullyan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/web-sig/attachments/20050429/feb40964/attachment-0001.pgp