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 75.87.112.250] > 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 - http://issues.apache.org/bugzilla/show_bug.cgi?id=42841 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 directives: ---------------------------------------------- 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 problem. ---------------------------------------------- -tom-
