tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Date Sat, 01 Nov 2003 06:57:07 GMT

"Jan Luehe" <Jan.Luehe@Sun.COM> wrote in message
news:3FA31998.7070605@sun.com...
> Remy,
>
> >> I agree we should help users come up with reasonable config values,
> >> but I'm just afraid rejecting any maxThreads < 10 or < 20 will send the
> >> wrong message, as if there was a bug in the way we dispatch incoming
> >> requests that requires at least 10 threads.
> >
> >
> > Nope, I disagree. If maxThreads < (say) 10, then set it to 10. Allowing
> > broken settings is bad, as there will be people out there who will use
> > them, and then will assume Tomcat is broken.
>
> I think changing people's config values behind their backs is not such
> a good idea in general.
>
> >> I think we should make any maxThreads setting work, as my patch
> >> attempts to do, and update the documentation to make users aware of
> >> the limitations they will run into when picking a low maxThreads.
> >> I think that would be the cleanest solution.
> >
> >
> > The rationale is that there's no point adding complexity and checks into
> > the very critical algorithm, simply to be able to support broken cases.
>
> I think we have 2 options:
> 1. Support any maxThreads setting (including "1", "2", etc.).
> 2. Reject any maxThreads values that are smaller than some
>     threshold and throw an error.
>
> The problem with 2. is that picking a value for the threshold (10? 20?)
> seems
> rather arbitrary. Therefore, I think we should do 1. The complexity it
> is adding is not significant and is well-documented.
>
> Please tell me you agree. :)
>

Well, I don't agree :).  There is no reason to accept a config value that
won't work, and it is cheaper and safer to handle in the config code then in
the critical runtime code (although, in this particular case, I admit that
the perfomance hit should be minimal).  Personally, I would be perfectly
happy with an enforced min setting of '2' (but Remy's suggestion is much
more practical, given that TC 5 does so much hand-holding already :).  As
long as the override is logged at WARN level, I don't see any problem with
enforcing a minimum.

I'm still -1 on this patch at heart, but I could be talked down to an
official -0 if enough of the rest of the community thinks that it is useful.

> Jan




---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message