Hello,
Over the weekend I posted here with questions about a problem where
variables stored in pnotes did not get garbage collected. Thanks to
some very helpful hints I was able to determine that mod_perl was
leaking pnotes in a request with an internal redirect. A patch to fix
that was posted to the dev list. If you have pages with internal
redirects where the redirected-to code uses pnotes then you should
watch out for leaks until the patch makes it into a full release.
I also had a second more serious problem I was hoping that would also
be solved, but it turns out it was completely different and not related
to mod_perl at all. Here is an example of the second leak we had:
my $dbh = DBI-connect(...);
$dbh-disconnect();
$dbh-do(create database 20030107_test);
$dbh-do(drop database 20030107_test);
That example leaks around 4k every request. In our server, there was
something else going on causing it to leak multiple megabytes per
request (I still don't know what). Simply adding in checks to reconnect
unless $dbh-{Active} does the trick. I'll submit a bug to the DBI
people, even though that is a horrible abuse of the class.
That example makes us look pretty dumb, let me explain how it happened
since it may affect you too. We do inter-request caching of $dbh in
pnotes. We rely on the destructor of DBI to disconnect; we don't use
disconnect() anywhere in our code. We do however use
Apache::AuthTIcket-- which does disconnect-- and we pass it our cached
$dbh. So you can see how the above example could occur: AuthTicket
grabs a dbh, then disconnects it, we still use it because we assume it
is connected like normal, but the DBI doesn't like that sequence of
events (it recovers the connection, but leaks).
Thanks for all your help, esp. the good hints about the per request
cleanup!
John
