It would be best, I think, if the patches actually used normal
httpd coding standards... The whole MAX_OVLP_LINE stuff is very
out of place.
On Apr 25, 2007, at 10:02 AM, Juerg Umhang wrote:
its now in bugzilla. patches submitted
http://issues.apache.org/bugzilla/show_bug.cgi?id=42216
-- juerg
On 4/20/07, Juerg Umhang <[EMAIL PROTECTED]> wrote:
hello
please consider this posting as a request for enhancement
httpd knows about his overload situation.
---- [error] server reached MaxClients setting, consider raising the
MaxClients setting
this overload is easily created by an external attacker. in case
of an
attack you have to react.
best done on a lower osi-layer (iptables, pf, ...).
realtime log analysis has his own odds and twists. we would prefer a
call
to an 'external helper procedure'.
in this context we have some questions:
-- do you think it makes sense to implement this feature ?
-- could it be done in a module (without the overhead of going
through
the
scoreboard for each pre_connection call) ?
It is reasonable to me for httpd to provide a module interface (hook)
so that a third-party module can take action when httpd reaches the
MaxClients (Unix) or ThreadsPerChild (Windows) condition. (Maybe the
hook just provides some basic statistics, and the module can
determine
whether the absolute limit has been reached or its own configurable
threshhold has been reached.)
A way that a module can do something reasonable without modifying the
server is to create a separate child process that monitors the
scoreboard at its own interval, and takes whatever action is
appropriate. That check can be infrequent enough that the
performance
overhead is negligible.
-- can we expect this enhancement in a future release ?
Some other committer can speak for themselves, but I wouldn't expect
it without a patch submitted.
btw: we hope to see separately configurable timeouts (
http://httpd.apache.org/docs/2.2/mod/core.html#timeout ) very soon.
I don't recall anyone here interested in fulfilling the goal
expressed
in that comment.
