Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: 
 <55907.212.190.198.36.1204101789.squirrel@webserver6.intec.ugent.be>
In-Reply-To: <1204033782.3976.63.camel@stjwks02.uk.ratedpeople>
References: 
    <28220.212.190.198.36.1203953831.squirrel@webserver6.intec.ugent.be>
    <813716b60802251733i2acb3de8s8288993b29e6b808@mail.gmail.com>
    <21448.212.190.198.36.1204014555.squirrel@webserver6.intec.ugent.be>
    <1204033782.3976.63.camel@stjwks02.uk.ratedpeople>
Date: Wed, 27 Feb 2008 09:43:09 +0100 (CET)
From: pthyseba@intec.ugent.be
To: users@httpd.apache.org
User-Agent: SquirrelMail/1.4.9a
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [users@httpd] Server hanging with requests in "W" state


> Whats your timeout and keepalivetimeout settings set to ?
>
> If you have them more than 15 secs ? then you'll DOS yourself
>
> IE will hold open connections to the server for as long as it can...
>


Timeout 300
KeepAliveTimeout 15

SSl config contains directives to deal with Internet Explorer SSL
keepalive issues as in previous post.

I've been thinking of loading additional logging modules to debug this
problem.

mod_log_forensic seems unnecessary: it only helps to check which
connections are hanging it seems, and I have no problem determining that
by looking at my server-status page.

Since these requests are hanging, they don't show up in the apache log
file, so I would need some module to log every bit of traffic as soon as
it arrives or is generated - maybe mod_dump_io will allow me to track
traffic over a connection as a function of time?

Also, after reading the "exact" definition of the Timeout directive, it's
still not very clear to me what will happen if a client requests a URL
which requires response from an application server and this application
server takes longer than 300s to respond? (I suppose this shouldn't happen
if all application server plugins have timeout settings > 300s)

Will apache terminate some connection (with the client? what with the
"dependent" connection to the application server?)?

Thanks,
Pieter

> On Tue, 2008-02-26 at 09:29 +0100, pthyseba@intec.ugent.be wrote:
>> Hello,
>>
>> > On 25/02/2008, pthyseba@intec.ugent.be <pthyseba@intec.ugent.be>
>> wrote:
>> >>  We're having some strange problems with our webservers (https),
>> which
>> >> are
>> >>  Apache 2.0.52 on RHEL4 and 2.0.46 on RHEL 3.
>> >
>> > This could be due to MSIE's duff SSL implementation. Do you have
>> > something like this in your SSL config?
>> >
>> > BrowserMatch ".*MSIE.*" \
>> >          nokeepalive ssl-unclean-shutdown \
>> >          downgrade-1.0 force-response-1.0
>> >
>> >
>>
>>
>> We do have this kind of line in our SSL configuration. However, we have
>> also seen this problem (512 W's with increasingly high "SS" values in
>> server-status, until even server-status can no longer be requested) on
>> our
>> non-ssl web servers, albeit a lot less frequently (possibly because of
>> lower load triggering our scenario less frequently).
>>
>> I'm wondering what the technical (apache, sockets, OS,...) reason is for
>> the absence of some "Apache kill switch" which would terminate (that is,
>> free the apache slot and make it available to another client) a
>> connection
>> with an "SS" value greater than some threshold - or is this supposed to
>> be
>> solved by any of the apache Timeout settings?
>>
>> If not, I'll have to dig further into the plugins we're running.
>>
>> Is there a good overview available which explains the relationship
>> between
>> Apache timeout settings and e.g. worker.properties (mod_jk) timeout
>> parameters (e.g. parameter1 >= parameter2) ? The documentation of each
>> package seems to only explain its own configuration directives, but I'm
>> thinking our problems may be related to some not-so-good combination of
>> timeout settings (at the moment they all have values > 0 and < infinite
>> though).
>>
>> Thx,
>>
>> Pieter
>>
>>
>> > noodl
>> >
>> > ---------------------------------------------------------------------
>> > The official User-To-User support forum of the Apache HTTP Server
>> Project.
>> > See <URL:http://httpd.apache.org/userslist.html> for more info.
>> > To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> >    "   from the digest: users-digest-unsubscribe@httpd.apache.org
>> > For additional commands, e-mail: users-help@httpd.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> The official User-To-User support forum of the Apache HTTP Server
>> Project.
>> See <URL:http://httpd.apache.org/userslist.html> for more info.
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>    "   from the digest: users-digest-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>    "   from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org