Re^2: how to timeout an operation under mod

Wow. Spawning a new child process for every time you want to run a max-10-second interaction with your database?

That sounds like the type of thing that motivated the creation of mod_perl and thus probably not something you want to do much from mod_perl.

That module's documentation does link to an alternative, DBI's docs on Canceling Operations. But it is also correct to note that doing this will likely cause stability problems. We do it but we have to implement seppuku code whereby the process can usually recognize when it has lost its mind (because all DBI calls fail after that point -- which requires the processes in the layer above to know how to retry requests) and to kill itself when that happens.

We also ask the database to timeout requests and that doesn't appear to introduce instability but it also appears to not always work (queries certainly sometimes run quite a bit longer than the specified maximum time-out). This, of course, varies based on how well such time-outs are supported by your particular database.

So, yeah, it is a mess.

- tye

Comment on Re^2: how to timeout an operation under mod_perl (fork?!)

Replies are listed 'Best First'.
Re^3: how to timeout an operation under mod_perl (fork?!) by perrin (Chancellor) on Sep 07, 2008 at 16:31 UTC
Sam and I came up with this while working on a project together that had the potential to generate very long-running queries. We tried a few other things before doing it this way, and they all had downsides. The potential for trouble when you use unsafe signals with XS code is pretty high. If forking really bothers you, you could do a more complicated approach with a prefork server. You do mention that you already use the unsafe signals approach. If that's working for you, what more were you looking for?	[reply]
Re^4: how to timeout an operation under mod_perl (looking) by tye (Sage) on Sep 07, 2008 at 16:42 UTC
The original poster was looking for something. I was not looking for something, I was pointing out what is probably the major drawback to the solution you offered and pointing out alternatives and some of the major drawbacks of them. But, no, none of them work very well, in my experience. It is rather sad that we can't have signals interrupt DBI while just preventing the signal action from bubbling up to the next higher level of abstraction until that level of abstraction is at a safe point for it to be interrupted. Perl's implementation of "safe signals" just never interrupt a long-running DBI call. That should be considered a bug to be fixed (without having to resort to "unsafe signals"). - tye	[reply]
Re^5: how to timeout an operation under mod_perl (looking) by perrin (Chancellor) on Sep 07, 2008 at 16:54 UTC
Sorry tye, didn't notice that the name had changed before I replied. Having safe signals that could interrupt DBI would be ideal. This is common enough that maybe DBI actually needs special handling for timeouts built in.	[reply]
Re^6: how to timeout an operation under mod_perl (looking) by ysth (Canon) on Sep 08, 2008 at 04:57 UTC
Re^7: how to timeout an operation under mod_perl (EINTR) by tye (Sage) on Sep 08, 2008 at 06:37 UTC


go ahead... be a heretic
	PerlMonks

Re^2: how to timeout an operation under mod_perl (fork?!)