You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "tony@clearfox.com" <to...@clearfox.com> on 2005/08/05 20:42:56 UTC

:Apache2 IO flush: (103) Software caused connection abort

 I have been getting some strange error on my system lately, so I took 
the time to completely upgrade my server last night to see of I could 
fix the problem with new updates. First thing this morning the errors 
re-surfaced.

 The error I'm getting is

:Apache2 IO flush: (103) Software caused connection abort at 
/pathtosite/admin.sd line 1136,

 Admin.sd is mine and is a mod_perl file. It uses some basic modules

    use CGI qw/:standard/;
    use CGI::Cookie;
    use CGI::Compress::Gzip;
    use Time::Local;
    use MIME::Lite;
    use CGI::Lite;

 I have added use Apache::DBI; to my startup.pl file so that mod_perl 
maintains the persistent connection to my database. I have a single 
database on the server. My website with all it's mod_perl files create 
approx. 20 connections to the MySql Server.

 I currently have the following installed.

 Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7a PHP/5.0.4 
mod_perl/2.0.1 Perl/v5.8.7

 My website also runs under an https connection. It's mandatory to 
connect to the site.

 Now, about the error, at line 1136 of admin.sd is this line.

 print $html;

 And that's it. All the files creating the error say the problem line in 
the file is a line which prints the output of the cgi.

 My cgi's do a lot of mysql queries, open a template, build a page, and 
output the page in a single print command. print $html;

 My os is "Fedora Core release 2 (Tettnang)"

 This is all the info I can think of to provide context for my errors.

 If anyone has any ideas, I'll try them.

 One more thing, the errors happen at a low ratio to successful 
requests. So much so, I've only gotten one of my testers to produce the 
error. I have never been able to do it. And the tester said nothing 
appeared wrong on the screen. No internal server error, just appears as 
a normal successful page request.

 Everytime I see the errors come in, I call my clients and ask if 
they've seen any errors. I normally get a no to that question, and twice 
I've heard white pages being returned. Could have been many other things 
though. I think the errors on behind the scenes.

 The only reason I know about them is because if this

    ErrorDocument 400 /error.osn
   ErrorDocument 401 /error.osn
   ErrorDocument 403 /error.osn
   ErrorDocument 404 /error.osn
   ErrorDocument 405 /error.osn
   ErrorDocument 408 /error.osn
   ErrorDocument 410 /error.osn
   ErrorDocument 411 /error.osn
   ErrorDocument 412 /error.osn
   ErrorDocument 413 /error.osn
   ErrorDocument 414 /error.osn
   ErrorDocument 415 /error.osn
   ErrorDocument 500 /error.osn
   ErrorDocument 501 /error.osn
   ErrorDocument 502 /error.osn
   ErrorDocument 503 /error.osn
   ErrorDocument 506 /error.osn

 The osn file is a standard perl file which emails me the %ENV values. 
So I can quickly take care of the error.

 The problem is, the :Apache2 IO flush: error is getting reported, but 
the user see's no error. error.osn should present an html page stating 
the error was reported and will be taken care of. Instead the page 
successfully renders and send me an error. Sending an email when no 
error is presented to the user also slows that request.

 Can anyone help? If not, I'm going to open a bug report to Apache.

 Thanks,
 Tony


Re: :Apache2 IO flush: (103) Software caused connection abort

Posted by Stas Bekman <st...@stason.org>.
tony@clearfox.com wrote:
> 
> I have been getting some strange error on my system lately, so I took 
> the time to completely upgrade my server last night to see of I could 
> fix the problem with new updates. First thing this morning the errors 
> re-surfaced.
> 
> The error I'm getting is
> 
> :Apache2 IO flush: (103) Software caused connection abort at 
> /pathtosite/admin.sd line 1136,

[...]
> Now, about the error, at line 1136 of admin.sd is this line.
> 
> print $html;

As you are using perlio layers (i.e. print() and not $r->print()), the 
error comes from:

src/modules/perl/modperl_io_apache.c:174:      ":Apache2 IO flush");

where it tries to flush the current STDOUT filehandle:

     MP_RUN_CROAK(modperl_wbucket_flush(rcfg->wbucket, FALSE),
                  ":Apache2 IO flush");

You can eval { } that print statement and deal with the exception, as 
explained here:
http://perl.apache.org/docs/2.0/api/APR/Error.html#Description

> The problem is, the :Apache2 IO flush: error is getting reported, but 
> the user see's no error. error.osn should present an html page stating 
> the error was reported and will be taken care of. Instead the page 
> successfully renders and send me an error. Sending an email when no 
> error is presented to the user also slows that request.

Are you saying that the exception is ignored by perl and the code 
continues to run just fine? I doubt this is the case. I think what happens 
is that the data is sent to the client and then for some reason the flush 
fails to finish, but the user has already received all the data. Probably 
due to your errordocument setup, the user doesn't get to see the error.

Again the error most likely happens at the very end of the response 
sending. May be the client disconnects too fast, before mod_perl had the 
chance to make sure that the buffers are empty. but it looks like some 
data must be present in the buffer for this condition to happen, as:

MP_INLINE apr_status_t modperl_wbucket_flush(modperl_wbucket_t *wb,
                                              int add_flush_bucket)
{
     apr_status_t rv = APR_SUCCESS;

     if (wb->outcnt) {
         rv = modperl_wbucket_pass(wb, wb->outbuf, wb->outcnt,
                                   add_flush_bucket);
     }
    [...]
     return rv;
}

i.e.  wb->outcnt returns true. you could probably add some debug to 
modperl_wbucket_pass to see what's inside the buffer when it fails to flush.

> Can anyone help? If not, I'm going to open a bug report to Apache.

I doubt it has anything to do with Apache. Either try to play with the 
above suggestions, or we'll need a test case we can reproduce the problem 
with.


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com