Remy Maucherat wrote:
I looked at this yesterday, and while it is a cool hack, it is not that useful anymore (and we're also not going to use the concurrent utilities in Tomcat, so it's not really an option before we require Java 5). The main issue is that due to the fact keepalive is done in blocking mode, actual concurrency in the servlet container is unpredictable (the amount of processing threads - maxThreads - will usually be a lot higher than the actual expected concurrency - let's say 100 per CPU). If that issue is solved (we're trying to see if APR is a good solution for it), then the problem goes away.
I'm still trying to understand the APR connector, but from what I see it is still mapping one socket ( 'keep alive' connection ) per thread. That's how it allways worked - but it's not necesarily the best solution. The only thing that is required is to have a thread per active request - the sleepy keep alives don't need thread ( that could be implemented using select in the apr, or nio in java )
Your patch is basically a much nicer implementation of maxThreads (assuming it doesn't reduce performance) which would be useful for the regular HTTP connector, so it's cool, but not worth it. Overall, I think the way maxThreads is done in the APR connector is the easiest (if the amount of workers is too high, wait a bit without accepting anything).
That's a tricky issue :-) In some cases ( like load balancing ) not accepting is the right solution, but in other cases droping connections is not what people want ( in particular if most of the threads are just waiting on keep alives ).
( sorry if I missed some details in the new implementation :-)
Costin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
