Peter J. Holzer escribió:
On 2008-04-25 21:24:17 +0200, Jose Luis Martinez wrote:
Peter J. Holzer escribió:
You caught it!!! It did the trick!
As I wrote previously, my guess is that both the mysql library and the
tls library catch SIGPIPE but don't call the previously installed signal
handler. So only one of them gets called (whichever is registered last)
and the other one loses.
So before patching the qp core in the respond method (Matt Sergeant
commented: "But I removed it because then alarm() features VERY heavily
in the performance profiling as an expensive system call.").
I chose to work around the DBD::mysql to make it behave...
my $sighandle = $SIG{'PIPE'};
my $dbh =
DBI->connect('DBI:mysql:database=xxx;host=localhost;port=3306',
'xxx','xxx') or
$self->log(LOGDEBUG, 'Could not connect ' . DBI->errstr()) ;
$SIG{'PIPE'} = $sighandle;
It seems the DBD::mysql uses the SIGPIPE to reconnect to the mysql in
case the connection is lost. Good bye feature!
Looks like Apache & DBD::mysql have or have had the same problem from
this post...
Found this:
http://mail-archives.apache.org/mod_mbox/httpd-dev/199903.mbox/[EMAIL PROTECTED]
No, but there are at least two layers below that: The PerlIO layer and
the TLS layer. Either one could retry an unsuccessful write if the
actual cause of the error was lost.
I'll try to contact the author of the TLS layer so that instead of
depending on the signal, maybe he can depend on the return value of the
writes (EPIPE) to cancel out... (Seems like a more stable solution...
that way external modules cannot influence you).
Thanks for all the help and comments.
Jose Luis Martinez
[EMAIL PROTECTED]
CAPSiDE
