"Jan Luehe" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
