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. :)
Jan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
