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 Thu, 18 Feb 2010 20:36:25 GMT
Wow, thanks Eric ! That seems to be very nice, I'll give it a try and will report later here
if avoiding system() calls reduce the number of aborted connections.

Heiko

Am 18.02.2010 um 17:24 schrieb eric.berg@barclayscapital.com:

> I'm starting to use Gearman to get around this whole problem.  We use a lot of external
processes for many things, so this issue wtih Apache2 really bit me hard in the bee-hind.
 I've gone to great lengths to work around it, but so far the job queue approach seems to
be the most elegant and least problematic approach.  Of course, the recommendation came from
the gentle folks on this list originally.
>  
> Eric
> 
> From: Heiko Weber [mailto:heiko@wecos.de] 
> Sent: Thursday, February 18, 2010 3:22 AM
> To: Salvador Ortiz Garcia
> Cc: mod_perl list
> Subject: Re: [mp2] mod_perl closes apache's stdin and/or stdout
> 
> Salvador,
> 
> to avoid such issues my "external" tasks don't use STDOUT, STDIN or STDERR. They take
their parameters from control files and write their results back to a status file. This tasks
don't send any output back to the browsers. As I said, usually some "sudo's to change some
system settings. 
> 
> Well, I could replace all system() calls and just store the task jobs into a database
table, to schedule a background job with cron to check and complete this tasks, but then I
lost the immediately feedback to the user/browser ... AND this is a lot of work for me - 
unless I can exactly repeat the issue I am not sure if it is worth to try it.
> 
> Currently it feels to me like a "leakage", sometimes a httpd/mod_perl/process do something,
and later (maybe when working on the next client request) STDOUT is closed. This makes it
hard to create a sample program to repeat it. Within a single script I can do almost everything:
call system(), open DBI connections, write to STDOUT, ... everything seems to be fine.
> 
> Heiko
> 
> Am 16.02.2010 um 23:26 schrieb Salvador Ortiz Garcia:
> 
>> On 02/05/2010 12:16 PM, Heiko Weber wrote:
>>> 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
>>>   
>> Of course STDOUT, STDIN, and STDERR get closed, not by mod_perl but by apache. Every
UNIX  process when demonized must close them to detach from its controling terminal.
>> 
>> Apache reopens STDERR to its log file, but STDOUT and STDIN remain closed.
>> 
>> Maybe de confusion arises from the fact that when executing a CGI the server connects
them to the client socket, but in mod_perl you are in the deamon process space.
>> 
>> Please check "Advanced Programing in the UNIX environment", chapter 13: "Daemon processes"
by W. Richard Stevens.
>> 
>> Regards.
>> 
>> Salvador.
> 
> -- 
> Wecos <> Heiko Weber Computer Systeme
> D-21644 Sauensiek <> Immenweg 5
> heiko@wecos.de <> http://www.wecos.de
> _______________________________________________
>  
> This e-mail may contain information that is confidential, privileged or otherwise protected
from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or
redistribute it by any means. Please delete it and any attachments and notify the sender that
you have received it in error. Unless specifically indicated, this e-mail is not an offer
to buy or sell or a solicitation to buy or sell any securities, investment products or other
financial product or service, an official confirmation of any transaction, or an official
statement of Barclays. Any views or opinions presented are solely those of the author and
do not necessarily represent those of Barclays. This e-mail is subject to terms available
at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent
to the foregoing.  Barclays Capital is the investment banking division of Barclays Bank PLC,
a company registered in England (number 1026167) with its registered office at 1 Churchill
Place, London, E14 5HP.  This email may relate to or be sent from other members of the Barclays
Group.
> _______________________________________________

-- 
Wecos <> Heiko Weber Computer Systeme
D-21644 Sauensiek <> Immenweg 5
heiko@wecos.de <> http://www.wecos.de
Tel. +49 (4169) 91000 <> Fax +49 (4169) 919033
_______________________________________________________________
This email may contain confidential and privileged material for
the sole use of the intended recipient. Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient please contact the sender and delete all copies.
_______________________________________________________________
Diese E-Mail kann digital signiert sein. Falls Ihr E-Mail-Programm
nicht ueber die notwendigen Prueffunktionen verfuegt, ignorieren
Sie bitte die angehaengte Signatur-Datei.
_______________________________________________________________
This email may be digitally signed. If your email software does
not support the necessary validation feature, please disregard the
attached signature file.
_______________________________________________________________


Mime
View raw message