On Sun, 2006-10-29 at 17:13 +0100, Robert Olofsson wrote:
> Oleg Kalnichevski wrote:
> > I have completed the first cut at the non-blocking NIO HTTP transport.
> > Both client and server side implementations are (more or less) feature
> > complete at this point.
> > These are the sample apps demonstrating the new API in action
> > ...
> > Before I go on hacking I would love to get some initial feedback. Please
> > let me know what you think
>
> I have only had a quick look, I am currently busy with my own proxy.
>
> One thing with the example code that looks suspicious to me is the keep
> alive handling both the client and the server contains something like:
> if (!this.connStrategy.keepAlive(response, context)) {
> conn.close();
> }
>
Hi Robert
For the client side demo this code does not make any sense indeed. As
Roland said this is just to show the way the API is meant to be used.
> Sure it is only a few lines of code, but why not say that client and
> server always close the connection and then handle persistent
> connections on a higher level (by the connection manager or whatever it
> is called).
> The current code demands that all users of http client does the right
> thing with regards to keep alive.
>
> One thing for the wish list that could be nice to have: support for
> FileChannel.transferTo and FileChannel.transferFrom. At least on linux
> they become sendfile. If you want to build a fast web server it is
> needed. The api for transferTo/From is a bit different from read + write
> since data is never in user space. Any thoughts?
>
This would call for some really hard design decisions. One can either
(1) expose the underlying socket channel in the public API, which is
kind of bad IMO or (2) extend ContentDecoder and ContentEncoder
interfaces with methods that take FileChannel as an input parameter.
I am not sure this all is worth the trouble, as the raw throughput is
certainly not one of NIO's strong points. As far as I can tell classic
blocking IO easily outperforms NIO in terms of raw throughput by as much
as 2 to 3 times, when the number of concurrent connections is around
200. I doubt the use of FileChannel#transferTo/From would dramatically
change the situation.
Oleg
> /robo
>
>
> ---------------------------------------------------------------------
> 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]
