On Fri, 2008-01-11 at 16:10 +0000, Christiaan Lamprecht wrote: > Thanks Ronald, > > After much reading and looking through the dev mailing list it seems > that "pipelining" is what I was looking for. Though saying that, it > does not seem to be very well supported in general. MozillaZine seems > to think that pipelining is not very well supported by some servers (I > assumed pipelining is only a client side concern?) and the java JDK > (up to 1.5, probably 6 too) does not support it either. Does the new > HttpCore 4 support it?
Hi Christiaan, The NIO based HTTP connection classes in HttpCore are fully pipelining capable. However mainly because the pipelining of entity enclosing requests and the expect-continue handshake are pretty much mutually exclusive (well, one _could_ use disable pipelining before executing a request with expect-continue handshake on and re-enable it afterward, but I am digressing), we chose to support the expect-continue handshake required by the HTTP spec instead of the pipelining in all protocol handlers shipped with HttpCore. Having said that, one could more or less easily develop custom protocol handlers that do the pipelining at the expense of the support for the expect-continue handshake. > (httpcomponents-dev mentioned that it might do > by now - post made about a year ago) or should I be looking at > HttpAsync or something else? > > And just by the by, I thought NIO can serve more connections than > using blocking I/O? Or perhaps only when the server is fully loaded? > Not necessarily. Blocking I/O tends to perform better than NIO when it is constantly busy pumping data. NIO on the other hand tends to be much more efficient when there are lots and lots of connections that sit idle most of the time, because the system does not have to constantly switch thread contexts just to check on the status of an I/O operation. Generally NIO suits better for high-latency scenarios and generally it can handle more connections because the number of concurrent connections is not limited by the pool of worker threads. Hope this helps Oleg > > Thanks again! > Christiaan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
