"Jan Luehe" <[EMAIL PROTECTED]> wrote in message
Remy,
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 agree with Bill. Hand holding is good :)
Remy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
