Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday March 02, 2007
11:02 AM

DBI, forking, and losing mysql connections

[ #32546 ]

Several hours later, I can finally lean back and relax after a one-line change in a program fixed a bug that another programmer and I spent hours failing to solve. Naturally, I found the solution two minutes after he left for the weekend, so I can't even crow about it until Monday.

We have a program which forks off several children to query whois servers. Unfortunately, the parent database handle was usually, but not always, going away. When it did go away it appeared to do so at random places in the code. The programmer who wrote the code was careful to ensure that each child was creating their own database handle, but I noticed in the code that 'connect_cached' was being used by default. Worried that everyone was sharing a database handle, I forced it to not used a cached copy if the PID was different, but my database handle still kept going away.

Eventually, we disabled the forking code and the problem went away, so we knew it was forking related. After many attempts to fix the problem, we were ready to table it until Monday with the consideration of possibly disabling the feature on our Web site.

That's when I stumbled across this post on Perlmonks. The symptoms were identical to ours. runrig, my hero for the day, mentioned the DBI InactiveDestroy attribute. Setting this to a true value in the parent (but not the child) eliminated the implicit disconnect that was apparently happening in the DBI DESTROY. I still have no idea why child finalization was killing the parent process (and doing so randomly, I might add), but the cargo-culted solution has saved the day.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I think SpamAssassin is going through something like this right now too :-)
  • Wow, looks like we're having the same problem right now. We had to temporarily disable most of the functionality of a website (due to changed laws in germany) which lowered the usage of the website's application to almost zero. Could this stuff also happen on a low traffic mod_perl website?
  • I've seen the same thing, presumably the MySQL protocol has some sort of quit command which the child process is sending (rather than simply closing the handle which would be OK).

    I worked around it by bypassing destroy handlers via POSIX::_exit, but looks like InactiveDestroy is a better approach.