|
Jim Gallacher
jpg at jgassociates.ca
Mon Jul 17 07:53:11 EDT 2006
Michael Kleiber wrote: > >> Other people have no problems with sessions when using prefork. You more >> than likely have some problem with your machine configuration in >> respect of >> mutex locks or some other area. >> >> What version of mod_python are you using? What command line options did >> you use when you ran "configure" to build it, or did you use a RPM >> version? >> >> Also, what sort of data are you trying to put into the session object? >> Do you >> have multiple independent instances of Apache running on the same box >> with both running mod_python? >> >> Graham >> > I have tried the packaged version of apache, mod_python etc. of Ubuntu > Dapper but have also compiled the newest version from source. I used the > prefork module and wanted to control the started child processes. I used > the following config: > > <IfModule prefork.c> > StartServers 1 > MinSpareServers 1 > MaxSpareServers 1 (or 0 I can't remember exactly right now) > MaxClients 1 > MaxRequestsPerChild 0 > </IfModule> > > > Therefore I only had one child process running and only one mutex was > created (from apache error log when starting the server). With this not > even a simple Session() object could be created. > > This was for my local test system where I did not want any extra (not > needed) child processes. Not a likely config in any real environment but > it gave me headaches for quite some time. > Try increasing the MaxClients to 2 or don't lock your sessions. You are likely only creating one mutex at startup. The number of mutexes created is based on the StartServers and MaxClients directives up to some maximum number. Check your error.log at start up to confirm this. [Mon Jul 17 07:40:58 2006] [notice] mod_python: Creating 8 session mutexes based on 50 max processes and 0 max threads. Session requires at least 2 mutexes, one of which is reserved for locking the dbm file, and the rest for locking the session itself. For testing you could try turning off locking when you create your session instance, which should fix the problem. sess = Session.Session(req, lock=0) Since will only be making one request at a time when testing you don't need to worry about any race conditions resulting from making multiple requests for the same session data. At times we have recommended that people use a configuration similar to yours for testing, so I guess we really should increase the minimum number of locks to 2 instead of 1. Jim
|