Sticky pnotes conclusion

[John Heitmann]

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