perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Heiko Weber <he...@wecos.de>
Subject Re: [mp2] mod_perl closes apache's stdin and/or stdout
Date Fri, 05 Feb 2010 18:16:03 GMT
Hi André,

I know what you mean, and I can't agree with you - the server response time is really low
- most pages are finished loading in less 1-2 seconds, and the overall load of the server
is at a low level. I believe there is an issue, maybe something what Jon is talking about,
I also using some "system()" call's to execute sendmail or sudo tasks, so maybe STDOUT really
gets closed - I have no idea. I only see the abort messages in errorlog very frequent, maybe
3-4 per minute.

Heiko

Am 05.02.2010 um 15:49 schrieb André Warnier:

> 
> Heiko Weber wrote:
>> Dear List-Members,
>> with interest I found the below thread. Starting in Oct. or Nov. last year I am getting
a lot of messages in apaches error_log like:
>> [Fri Feb  5 11:07:09 2010] -e: Software caused connection abort at ...
>> And it always happen in a print to STDOUT. I notice that it also happen with smaller
scripts (running under mod_perl) with no database connection, i.e. scripts which do the following:
> ...
> 
>> So I am really wondering whats going on here. The above file works for years now,
has not been touched and the content of the opened files isn't empty. The server is a FreeBSD
7.0, apache apache-2.2.14, prefork MPM, mod_perl2-2.0.4 everything from a current freebsd
ports.
> 
> This seems to be happening when your server-side module is trying to send data back to
the browser who requested it.
> The most common explanation is that, by the time your module tries to send the answer,
the browser connection does not exist anymore, because the browser (or something in-between
the server and browser) closed it.
> This happens for example when the user clicks on a link which triggers your module, then
changes his mind and clicks somewhere else (or closes the window or the browser) before your
module has finished sending the response.
> In other words, he hung up on you.
> 
> It is quite frequent and nothing to worry about in principle.
> 
> Where it would get more worrying, is that it could indicate that your application is
taking too long to send back a result to the user, and that he's losing patience.
> If a user clicks on a link and expects an answer, he will usually wait only 10-20 seconds
maximum before starting to worry.  He may then just click again on the same link, which would
have the same effect.



Mime
View raw message