On Apr 9, 2005 3:00 AM, Jim Gallacher <jg.lists@sympatico.ca> wrote:
> Gregory (Grisha) Trubetskoy wrote: 
e[vbcol=seagreen] 
n[vbcol=seagreen] 
s[vbcol=seagreen] 
>=20
> Sorry for the long post here - just kind of thinking out loud.
>=20
> I've been playing with the code Nicolas committed and found the file
> locking is not working quite right. I couldn't figure out what was going
> wrong until I re-read Grisha's comments.
>=20
> There is a deadlock when accessing an existing session with session
> locking on. A DOS results for that session, and in the worst case a
> complete DOS for any connections. The following bash script demonstrates
> the effect:
>=20
> #!/bin/sh
> ab -n 1 http://localhost/session_test.py
> ab -n 1 -C  pysid=3D723b98c0abf885a97b8bdc8d806b4bd8
 \
>     http://localhost/session_test.py
>=20
> where pysid is a valid session id.
>=20
> The first call to the url will succeed, while the second one will fail
> with ab timing out. Here is the FileSession program flow as I see it:
>=20
> sess =3D FileSession.FileSession.__init__(req,lock=3D1)
>    - calls BaseSession.__init__(req,lock=3D1)
>=20
> BaseSession.__init__()
>    - gets the existing session id from the request cookie
>    - acquires a lock for this session
>    - registers the unlock_session_cleanup
>    - calls BaseSession.load()
>=20
> BaseSession.load()
>    - calls self.do_load() which is overriden in FileSession
>=20
> FileSession.do_load()
>    - attempts to acquire a lock on the session, but is blocked since
> session was previously locked in BaseSession.__init__()
>    - client times out
>    - unlock_session_cleanup is never run so lock is never released
>    - this apache thread or child is deadlocked
>    - access to this session is blocked forever
>=20
> Call the url enough times for an exisiting session, and apache will
> reach MaxClients and refuse additional connections. DOS. oops.
>=20
> I assume that overriding BaseSession.load() is the best way to change
> the locking behaviour and fix the problem. I haven't worked out the
> implications of that yet - I guess I need a little more head scratching
> time.
>=20
> On another note, I also wonder if this type of locking problem might
> also be a factor in http://issues.apache.org/jira/browse/MODPYTHON-31
>=20
> Regards,
> Jim
>=20
>=20

Given the fact that getting the session object holds a lock for the
whole duration of the request (from the session instantiation to the
request cleanup), the locking code I've wrote in FileSession.do_load
is redundant. What I don't understand, though, is why I didn't see any
deadlock when I tested the code, whereas you see one. I assumed that
the APR locking facility was reentrant, but maybe it's not. Or maybe
it's reentrant on Win32 with threads, and not in an over environment.

Anyway... let's get rid of this redundant locking code in FileSession
and the problem will be solved. The only problem, as Grisha pointed
out, is that locking is an optional feature, you can disable it by
passing lock=3D0 in the session constructor call. If locking is
disabled, there is a potential for trouble in FileSession. For now,
I'll just say that if you want to disable locking, then you know what
you are doing...

As for MODPYTHON-31, as Graham noted in the comments, it looks like a
problem in the reporter's configuration file. I've closed the bug
report.

Regards,
Nicolas

[ Post a follow-up to this message ]