[mod_python] Session Hanging Problems

Harish Agarwal harish at octopart.com
Tue Dec 4 13:52:09 EST 2007


These aren't large files - this is the most typical request we serve  
up,  which under normal circumstances takes < 1 second to send (based  
on timers I've sent up).  The case where this request is taking a long  
time (I've noticed up to 300 seconds) is very rare, compared to how  
many times we serve the page up, but is still a problem as it causes a  
pile-up of session hangs which want the same mutex lock.

It sounds like the best way to deal with this problem, given the below  
issues surrounding session unlocking after every session.save(), is to  
do

session.unlock()
req.write(data)

before every single req.write I'm doing - is that correct?  If so, my  
only point is that this seems to go against the general philosophy of  
never explicitly having to do a session unlock (and in addition, makes  
the code which goes into our mod_python handlers less clean).  Don't  
get me wrong, I really appreciate mod python and it has served me  
incredibly well, but my apologies if, as an end-user, I'm finding it  
difficult to use it in what I think is a pretty standard way without  
encountering problems as our traffic goes up.

If you don't mind me asking, why are apache's mutexes limited?  If I  
were to switch to fcntl.flock, would we no longer have a limited pool  
of mutexes?

-Harish


On Dec 4, 2007, at 10:39 AM, Jim Gallacher wrote:

> Harish Agarwal wrote:
>> Have you noticed any performance issues?  I want to make sure to  
>> keep things fast and am worried that departing from the Apache lock  
>> system will degrade performance.  Why was mod python designed to  
>> use the apache system and not use session specific locks?
>
> I wasn't around when session handling was first introduced, but I  
> assume the apache mutexes where used so that mod_python would be as  
> cross-platform as possible. Python's fcntl.flock() is only available  
> on *nix platforms.
>
> The big drawback with apache's mutexes is that we are dealing with  
> limited resource.
>
>> Also a note for the list - I'm now explicitly unlocking the session  
>> after each save to ensure that the session isn't locked during a  
>> req.write call.  I've seen one hang since then, but in twelve  
>> hours, that is much much better than the issues I was seeing before.
>
> Are you re-locking the session before modifying the session object?  
> If not then you've got a possible race condition and you risk losing  
> session data. The only safe way to do this multiple times within a  
> single request is:
>
> session.lock()
> session.read()
> session['stuff'] = 'whatever'
> session.save()
> session.unlock()
>
> Each read / save pair results in a disk access and unpickling/ 
> pickling the data, which may not be all that great for high  
> performance.
>
> You'll need to make sure the above sequence happens every time you  
> modify the session object. If your code is complicated it would be  
> pretty easy to lose some session data. You'll also need to make darn  
> sure that there are matching lock/unlock pairs. If not you'll  
> deadlock the session and in pretty short order you'll end up with a  
> self inflicted denial of service as apache runs out of mutexes. Make  
> sure you put a try/finally block in there with an unlock() in the  
> finally section.
>
>> I think that this problem directly contradicts the general  
>> philosophy behind using the mod_python session handling scheme - I  
>> feel like I've read, a few times now, that there is no reason to  
>> have to explicitly unlock sessions,
>
> Then you missed comments about the problem with long running  
> requests and session locking, such as the case of a large download.  
> There are times when it really is advantageous to explicitly unlock  
> a session. It's always best if you can finish with your session  
> object before sending the file.
>
> session['stuff'] = 'whatever'
> session.save()
> session.unlock()
> req.sendfile("my_big_file.iso")
>
>> but this is an instance where running everything in its default  
>> configuration (not unlocking sessions, flushing the buffer on  
>> req.writes) causes serious hanging problems...  In addition,  
>> unlocking the session after each save doesn't sit well with me - I  
>> don't think the session is thread-safe now (given that there can be  
>> multiple save's per request).
>
> It's not even a question of being thread safe. With prefork or  
> worker mpms you are also dealing with multiple processes. If we just  
> had to worry about one process with many threads life would be much  
> easier.
>
> Jim
>
>> -Harish
>> On Dec 4, 2007, at 1:48 AM, David Janes wrote:
>>> I'll note for the list that I put in the changes I outlined above  
>>> ---
>>> that is, handled locking entirely ourselves rather than using  
>>> Apache's
>>> lock function -- and I haven't had a hang since.
>>>
>>> Regards, etc...
>>>
>>> --David Janes
>>> Founder, BlogMatrix
>>> http://www.blogmatrix.com
>>> http://blogmatrix.blogmatrix.com
>>> _______________________________________________
>>> Mod_python mailing list
>>> Mod_python at modpython.org
>>> http://mailman.modpython.org/mailman/listinfo/mod_python
>> _______________________________________________
>> Mod_python mailing list
>> Mod_python at modpython.org
>> http://mailman.modpython.org/mailman/listinfo/mod_python



More information about the Mod_python mailing list