Apache Mod-Python - _apache.emergency

Author

_apache.emergency_unlock function?

Jim Gallacher

2005-05-20, 5:45 pm

I'm spending some time today to work on the Session docs, and was
looking at the mod_python mail archives.

It seems that users quite often deadlock their sessions, and eventually
exhaust the max thread/processes available. The only way to kill the
deadlocked sessions is by re-starting apache.

What do people think of the idea of adding a function to _apache which
would unlock all locked sessions do resolve deadlocks. If there is a
least one thread/process available to handle the request then apache
could be effectively restored without a restart. I know that this is not
ideal, but it's better than killing the server altogether.

Code might look something like this, hacked from _global_unlock:

static PyObject *_global_emergency_unlock(PyObject *self, PyObject *args)
{

PyObject *server;
PyObject *key;
server_rec *s;
py_global_config *glb;
int index = 0;
apr_status_t rv;

if (! PyArg_ParseTuple(args, "OO|i", &server, &key, &index))
return NULL;

if (! MpServer_Check(server)) {
PyErr_SetString(PyExc_TypeError,
"First argument must be a server object");
return NULL;
}

s = ((serverobject *)server)->server;

apr_pool_userdata_get((void **)&glb, MP_CONFIG_KEY,
s->process->pool);

for (index = 0; index < glb->nlocks; index++) {
apr_global_mutex_unlock(glb->g_locks[index]);
}

Py_INCREF(Py_None);
return Py_None;
}

Just thinking out loud.
Jim

Nicolas Lehuen

2005-05-20, 5:46 pm

Why not, but I really think that we should find a simple way to solve
the problems created by building multiple sessions or multiple
FieldStorage instances on the same request.

In the Java (i.e. servlets) world, when you want a session, you just
ask for it on the HttpRequest object. If a session exist, you get it,
if not, it is created. If you never ask for a session, then it is not
created, this way a session is not mandatory for pages which do not
require it.

I really think the current way of building Session instances in
mod_python is weird. First, because it opens a whole bunch of bugs due
to multiple Session instantiation (i.e. deadlocks). Second, because
the Session hosting infrastructure is up to the developer (which can
choose between MemorySession, DBMSession or FileSession) whereas I
think it should be up to the hoster.

The session infrastructure should be defined in httpd.conf or a
..htaccess file, with something like :

PythonOption SessionInstantiation "FileSession(directory=3D'/tmp/sessions')=
"

Then, there would be a get_session() method on the request object,
that would check if a session is already present and if not would
execute the code defined in SessionInstantiation.

Something similar should be done with the form parsing mechanism.
Instantiating FieldStorage should be done my mod_python, not the
developer. The developer could then call req.get_uri_parameters() (all
the function names are of course subject to debate) to get the
parameters that were passed in the URI, req.get_form_parameters() to
get the parameters that were passed in a POST of content type
application/x-www-form-urlencoded, and req.get_combined_parameters()
for a combination of the two sets of parameters. Trying to read on the
request after a call to get_form_parameters() should raise an
exception, and conversely.

Solving these two problems would simplify a lot of code and could
please a lot of people, except from the fact that this would break
some compatibility with previous code

.

I know there is a lot of shouldas and wouldas in this mail but I
really feel that some people who are used to other web frameworks can
be horrified by some very low level issues that they have to solve by
themselves. Other web frameworks are a little more helpful. Do we
really want developers to loose time thinking about whether the number
of times they already instantiated a Session object ?

Regards,

Nicolas

2005/5/20, Jim Gallacher <jg.lists@sympatico.ca>:
> I'm spending some time today to work on the Session docs, and was
> looking at the mod_python mail archives.
>=20
> It seems that users quite often deadlock their sessions, and eventually
> exhaust the max thread/processes available. The only way to kill the
> deadlocked sessions is by re-starting apache.
>=20
> What do people think of the idea of adding a function to _apache which
> would unlock all locked sessions do resolve deadlocks. If there is a
> least one thread/process available to handle the request then apache
> could be effectively restored without a restart. I know that this is not
> ideal, but it's better than killing the server altogether.
>=20
> Code might look something like this, hacked from _global_unlock:
>=20
> static PyObject *_global_emergency_unlock(PyObject *self, PyObject *args)
> {
>=20
> PyObject *server;
> PyObject *key;
> server_rec *s;
> py_global_config *glb;
> int index =3D 0;
> apr_status_t rv;
>=20
> if (! PyArg_ParseTuple(args, "OO|i", &server, &key, &index))
> return NULL;
>=20
> if (! MpServer_Check(server)) {
> PyErr_SetString(PyExc_TypeError,
> "First argument must be a server object");
> return NULL;
> }
>=20
> s =3D ((serverobject *)server)->server;
>=20
> apr_pool_userdata_get((void **)&glb, MP_CONFIG_KEY,
> s->process->pool);
>=20
> for (index =3D 0; index < glb->nlocks; index++) {
> apr_global_mutex_unlock(glb->g_locks[index]);
> }
>=20
> Py_INCREF(Py_None);
> return Py_None;
> }
>=20
> Just thinking out loud.
> Jim
>

dharana

2005-05-20, 5:46 pm

I don't know if it's related but I'm having some troubles with the current
FileSession implementation. It causes a segfault when I do this:

- login creating a session and go to any page
(spend enought time looking down until session expires)
- f5 at the browser

apache segfaults and the only way to enter again is to manually delete the pysid
cookie.

I will try to find the root of the problem. It happened to me some weeks ago but
I incorrectly thought it was caused by something else.

Nicolas Lehuen wrote:
> Why not, but I really think that we should find a simple way to solve
> the problems created by building multiple sessions or multiple
> FieldStorage instances on the same request.
>
> In the Java (i.e. servlets) world, when you want a session, you just
> ask for it on the HttpRequest object. If a session exist, you get it,
> if not, it is created. If you never ask for a session, then it is not
> created, this way a session is not mandatory for pages which do not
> require it.
>
> I really think the current way of building Session instances in
> mod_python is weird. First, because it opens a whole bunch of bugs due
> to multiple Session instantiation (i.e. deadlocks). Second, because
> the Session hosting infrastructure is up to the developer (which can
> choose between MemorySession, DBMSession or FileSession) whereas I
> think it should be up to the hoster.
>
> The session infrastructure should be defined in httpd.conf or a
> .htaccess file, with something like :
>
> PythonOption SessionInstantiation "FileSession(directory='/tmp/sessions')"
>
> Then, there would be a get_session() method on the request object,
> that would check if a session is already present and if not would
> execute the code defined in SessionInstantiation.
>
> Something similar should be done with the form parsing mechanism.
> Instantiating FieldStorage should be done my mod_python, not the
> developer. The developer could then call req.get_uri_parameters() (all
> the function names are of course subject to debate) to get the
> parameters that were passed in the URI, req.get_form_parameters() to
> get the parameters that were passed in a POST of content type
> application/x-www-form-urlencoded, and req.get_combined_parameters()
> for a combination of the two sets of parameters. Trying to read on the
> request after a call to get_form_parameters() should raise an
> exception, and conversely.
>
> Solving these two problems would simplify a lot of code and could
> please a lot of people, except from the fact that this would break
> some compatibility with previous code

.
>
> I know there is a lot of shouldas and wouldas in this mail but I
> really feel that some people who are used to other web frameworks can
> be horrified by some very low level issues that they have to solve by
> themselves. Other web frameworks are a little more helpful. Do we
> really want developers to loose time thinking about whether the number
> of times they already instantiated a Session object ?
>
> Regards,
>
> Nicolas
>

Jim Gallacher

2005-05-20, 5:46 pm

dharana wrote:
> I don't know if it's related but I'm having some troubles with the
> current FileSession implementation. It causes a segfault when I do this:
>
> - login creating a session and go to any page
> (spend enought time looking down until session expires)
> - f5 at the browser

segfault? Yikes.

> apache segfaults and the only way to enter again is to manually delete
> the pysid cookie.
>
> I will try to find the root of the problem. It happened to me some weeks
> ago but I incorrectly thought it was caused by something else.

I'll see if I can reproduce the error as well.

Jim

> Nicolas Lehuen wrote:
>
>

Jim Gallacher

2005-05-20, 5:46 pm

Nicolas,

I agree 100% with all your comments. The emergency_unlock would really
just be a last desperate attempt to save your apache server from
deadlocks without resorting to a full restart. Doing a restart on a
development machine is one thing, but on a production server... I hate
restarts.

I've also been giving some thought to mod_python in a virtual hosting
environment. The idea that one site could hose all the other sites by
deadlocking all available threads/process is just too disturbing. I've
actually been thinking of the idea of somehow allocating mutex's on a
per site basis.

Nicolas Lehuen wrote:
> Why not, but I really think that we should find a simple way to solve
> the problems created by building multiple sessions or multiple
> FieldStorage instances on the same request.
>
> In the Java (i.e. servlets) world, when you want a session, you just
> ask for it on the HttpRequest object. If a session exist, you get it,
> if not, it is created. If you never ask for a session, then it is not
> created, this way a session is not mandatory for pages which do not
> require it.
>
> I really think the current way of building Session instances in
> mod_python is weird. First, because it opens a whole bunch of bugs due
> to multiple Session instantiation (i.e. deadlocks). Second, because
> the Session hosting infrastructure is up to the developer (which can
> choose between MemorySession, DBMSession or FileSession) whereas I
> think it should be up to the hoster.

Yes, the hoster must have control. Each session type has it's drawbacks,
and the responsibility to find the right balance should fall to the
server admin. This type of decision should not be left up to the
individual developer.

> The session infrastructure should be defined in httpd.conf or a
> .htaccess file, with something like :
>
> PythonOption SessionInstantiation "FileSession(directory='/tmp/sessions')"

I've never really been happy with the the dbm file or FileSession files
getting dumped into /tmp by default. Again, from the virtual hosting
angle it just seems too prone to problems. Putting this in httpd.conf at
least gives the server admin a chance to protect the website developers
from themselves and each other.

> Then, there would be a get_session() method on the request object,
> that would check if a session is already present and if not would
> execute the code defined in SessionInstantiation.

I was playing with something similar to this a few weeks ago. I was sort
of just blundering around, but it is the approach that makes the most
sense. No code to share - what I had was ugly and will absolutely make
your apache server go pear-shaped. I don't really grok Python reference
counting, and so my code has issues.

> Something similar should be done with the form parsing mechanism.
> Instantiating FieldStorage should be done my mod_python, not the
> developer. The developer could then call req.get_uri_parameters() (all
> the function names are of course subject to debate) to get the
> parameters that were passed in the URI, req.get_form_parameters() to
> get the parameters that were passed in a POST of content type
> application/x-www-form-urlencoded, and req.get_combined_parameters()
> for a combination of the two sets of parameters. Trying to read on the
> request after a call to get_form_parameters() should raise an
> exception, and conversely.
>
> Solving these two problems would simplify a lot of code and could
> please a lot of people, except from the fact that this would break
> some compatibility with previous code

.

What is the alternative? The current implementation is already somewhat
broken. Let's get something that's bulletproof and hopefully developers
will be happy to absorb some short term pain for long term gain.

> I know there is a lot of shouldas and wouldas in this mail but I
> really feel that some people who are used to other web frameworks can
> be horrified by some very low level issues that they have to solve by
> themselves. Other web frameworks are a little more helpful. Do we
> really want developers to loose time thinking about whether the number
> of times they already instantiated a Session object ?

To hell with developers - I don't want to waste *my* time.

The need
to be oh so very careful when using sessions is just too mentally
exhausting for me.

I haven't collected any stats, but I would not be surprised if 20% of
the problems (or confusion) on the mod_python mailing list could be
traced to session locking issues. Spending time on this would be worth
the effort for all concerned.

Regards,
Jim

> Regards,
>
> Nicolas
>
>
>
>
> 2005/5/20, Jim Gallacher <jg.lists@sympatico.ca>:
>
>
>