Not possible to track connection reset errors post-2.0.6?

[Ævar Arnfjörð Bjarmason]

On Wed, Apr 25, 2012 at 9:29 PM, Fred Moyer <ph...@apache.org> wrote:

When mod_perl 2.0.6 was released this is one of the things that was changed:

> PerlIOApache_flush() and mpxs_Apache2__RequestRec_rflush() now no longer throw
> exceptions when modperl_wbucket_flush() fails if the failure was just a reset
> connection or an aborted connection. The failure is simply logged to the error
> log instead. This should fix cases of httpd.exe crashing when users press the
> Stop button in their web browsers.
> [Steve Hay]

And this is the relevant commit:
http://mail-archives.apache.org/mod_mbox/perl-modperl-cvs/201105.mbox/%3c20110518093000.d37462388...@eris.apache.org%3E

I maintain an application where we logged these rflush and print
errors ourselves by:

 1. Re-blessing the Apache $r object into a clas sof our own:

 2. That class would define rflush/print as:

        sub print {
            my $R= shift;

            my $ret;
            eval {
                $ret= $R->SUPER::print( ref $_[0] ? ${ $_[0] } : $_[0] );
                1;
            } or warn_only_on_certain_apache_errors( "print", $@ );
            return $ret;
        }

        sub rflush {
            my $R= shift;
            eval {
                $R->SUPER::rflush( @_ );
                1;
            }
            or warn_only_on_certain_apache_errors( "rflush", $@ );
            return;
        }

 3. warn_only_on_certain_apache_errors would check if we got a
    connection reset error, if so log it to our own central
    cluster-wide logging system, else re-throw the exception.

It seems to me that after mod_perl 2.0.6 we'll lose this ability to
log these errors, and our server error logs will start to be mostly
the result of the new ap_log_error() call added in 2.0.6.

So my questions are:

 * Is there some better way that I've missed to hook into
   ap_log_error() like I'm doing with
   warn_only_on_certain_apache_errors() now so I can still log when
   these things happen.

 * Was this really needed in the first place given that you can quite
   easily just subclass the request object and provide your own
   print/rflush if you'd like to catch these?

   Even if there's some way to hook into the Apache error log printing
   mechanism I think just doing croak() and allowing you to catch it
   by writing your own subclass is a more elegant and Perl-like
   interface.