httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Donovan <>
Subject Re: mod_authn_dbd - internal server error after certain idle time
Date Mon, 09 Jul 2007 14:09:17 GMT
Danie Qian wrote:
> It is working a little better now after I set both DBDKeep and DBDMin to 
> zero. But I am still getting the internal server error from time to 
> time. Users usually can get pass the error by reloading the same page. 
> Here is the error messages in the log:
> [Sat Jul 07 02:56:44 2007] [error] (20014)Internal error: DBD [mysql] 
> Error: Lost connection to MySQL server during query
> [Sat Jul 07 02:56:44 2007] [error] [client] 
> authn_dbd_acquire: Error looking up josiahhansen in database

Unfortunately, DBD connection pooling (which is performed by the
apr-util reslist facility) presumes that connections last longer than
DBDTimeout, so just setting DBDKeep and DBDMin will not completely
eliminate the problem.

The proposed changes to the MySQL driver seem like a good idea and they
may help - but they will only help MySQL, not any other databases.

I entered a new APR bug and proposed a patch -
to change the interpretation of timeout so that it will work to avoid
this error.

With this patch, setting DBDTimout lower than the MySQL system variable
'wait_timeout' will ensure than expired connections never get used.

Likewise for Oracle 'IDLE_TIME', or IBM-DB2 'IDLE_TIMEOUT' - which are
similar to MySQL 'wait_timeout'.

In detail, here is how the patch would affect the behavior of mod_dbd

The behavior of DBDMax and DBDMin are unchanged.

DBDMax is still the maximum number of connections - both in-use and idle.

DBDMin is still the minimum number of idle connections, except when this
would cause DBDMax to be exceeded because Min + in-use > Max)

Without the patch:
DBDKeep was the minimum number of idle connections which were retained
after being used one or more times.
DBDTimeout controlled how long idle connections in excess of DBDKeep
remained available.
All connections were presumed to last forever.

With the patch:
DBDKeep is now the maximum number of idle connections, not the minimum.

DBDTimeout is now the maximum lifetime of a connection.  A connection
which has been idle longer than DBDTimeout will never be used.

The ramifications of the new algorithm are:
There will never be more than DBDKeep idle connections, although there
still can be additional in-use connections (up to DBDMax total connections).

If there is a DBDTimeout, the number of idle connections will shrink as
they expire down to a minimum of DBDMin idle connections.

If there is no DBDTimeout, once the number of idle connections gets up
to DBDKeep it will stay there indefinitely.

A possible weakness of the new algorithm is that DBDMin doesn't (and
never did) add any benefit when the connection pool is inactive enough
to let connections expire. There is still nothing which spontaneously
recognizes and closes expired connections during periods of no activity.
The replacement of an expired connection only happens when the expired
connection is about to be used for a database query.  Since this
weakness applies to inactive systems, it is not likely to be much of a



View raw message