--- Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: ... > If you absolutely sure you want to be able to handle > multiple requests > or responses simultaneously using just one worker > thread, NIO is the > only way to go.
True. A single worker thread probably need not be a goal, but perhaps it's useful to have M:N mapping between connections and worker threads. But then the question is, at what point does it make sense to switch from simple and reliably one-to-one mapping to a more complicated and higher-overhead solution. Which I think is part of the point you are making (and esp. that it's much more likely that point is reached earlier on server side). > Anyways, we want HttpCore to be as flexible and > versatile as possible. > This is my primary motivator for working on the NIO > extensions. All I am > saying the non-blocking I/O may not be the best > strategy in all cases > and should be used selectively where appropriate. > Benefits of NIO on the > client side seem lesser than on the server side. Sounds very reasonable, and I fully agree with that. I also appreciate your explanation of the issues, especially based on your experience with implementations. It sounds like the approach you were describing (and that has been discussed, and documented at wiki pages) can lead to significant improvements to scalability over existing http solutions, on both server and client sides. This is exactly why I am very interested in seeing the progress, -+ Tatu +- __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
