Hello, Stas Stas Bekman wrote:
alarm(300) is an Apache alarm. Can you see the perl's alarm calls earlier in the trace? since you tried alarm 1, grep for alarm(1).
[EMAIL PROTECTED] tauction]$ grep -P 'alarm' <strace.log alarm(0) = 0 alarm(300) = 0 alarm(300) = 300 alarm(0) = 300 alarm(1) = 0 alarm(300) = 0 alarm(0) = 300 alarm(300) = 0
seems it is here
Thanks. So you can see that Apache overrides perl's alarm:
> alarm(1) = 0 > alarm(300) = 0
I think what happens is that perl sets the alarm, but then Apache resets it again to its own value and its own sighandler. Even though it may restore the perl sighandle at the end it's happening too late.
So i'd try:
1)
You could try to lower Apache's IO timeout for this call. I can't see it documented (defined in Server.xs) but you can read/write server timeout values:
my $timeout_secs = 1; my $orig_timeout = $r->server->timeout($timeout_secs); $apr->param; # no perl alarm is now needed $r->server->timeout($orig_timeout_secs);
yep, that closes the connection after $timeout_secs and looks to me like the right solution.
However, If I try to stop apache it exits with 'Segmentation fault' (in case a timeout occured),
seems due to the fact that the perl code haven't had a chance to clean up. Can I trap this timeout ?
I don't think you can. I think this API is not really used by anyone, hence no wonder if it causes a segfault. Can you post a backtrace?
Did you set the perl trap as well? You shouldn't if you set Apache's timeout already. Just wrap $apr->param in eval {}; in the above snippet to trap the failure.
BTW, what happens if you set the Apache alarm to 0, does it still set it? Can you try:
my $orig_timeout = $r->server->timeout(0); $apr->param;
and then strace to see whether it sets it at all. I guess we can look at the source code, but strace is more fun ;)
2) I'm not sure this will work, since read will probably set the alarm after kill_timeout, so it won't accomplish that affect.
$r->kill_timeout; ... alarm eval here with $apr->param call ... $r->reset_timeout; http://perl.apache.org/docs/1.0/api/Apache.html#_r_E_gt_reset_timeout
that doesn't work
Ok, thanks for verifying.
3) Try Sys::Signal to set the perl alarm. I don't think though it'll give you the solution, since it was written to have the C level sighandlers restored after perl's sighandler was called. And recent Apache versions are supposed to work well with plain perl sighandlers.
it doesn't compile for me :((
Yes, I remember I had probs with recent perls too, but since it's not really needed and we know exactly what the problem is, let's just leave it alone.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
