hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpCore] NIO extensions (first take) are ready for review
Date Tue, 05 Sep 2006 19:25:43 GMT
On Sun, 2006-09-03 at 09:21 +0200, Roland Weber wrote:
> Hi Oleg,

Hi Roland

> here are a few comments, though they have little to do with NIO.
> - the examples and at least some of the implementation classes
>   are missing the Apache copyright notice in the source files

I'll fix that.

> - I still don't like the duplication of methods in IOSession
>   and HttpContext. The only reason I can see for not deriving
>   IOSession from HttpContext are the constants defined there.
>   Maybe we should separate declaration of the methods from
>   definition of the constants. Factor out the methods to a new
>   interface o.a.h.util.Attributable, derive both HttpContext
>   and IOSession from there?

I didn't want to make the public interfaces in the NIO module dependent
on HTTP specific interfaces unnecessarily. I do not see a problem with
deriving IOSession from HttpContext, though. 

> - The way you are using EntityTemplate in the examples,
>   I don't see the advantage over a StringEntity. For example:
>   EntityTemplate body = new EntityTemplate(new ContentProducer() {
>      public void writeTo(final OutputStream outstream)
>        throws IOException {
>           OutputStreamWriter writer =
>              new OutputStreamWriter(outstream, "UTF-8");
>           writer.write("<html><body><h1>");
>           writer.write("File ");
>           writer.write(file.getPath());
>           writer.write(" not found");
>           writer.write("</h1></body></html>");
>           writer.flush();
>      }
>   });
>   can be replaced by
>   StringEntity body =
>      new StringEntity("<html><body><h1>" +
>                       "File "+file.getPath()+" not found" +
>                       "</h1></body></html>",
>                       "UTF-8");
>   which is just as readable and doesn't need an inner class.

Sure. Some people just insist on being able to write directly to the
output stream. I want to demonstrate that this is possible with the
HttpCore API. I am not trying to say this approach is any better than
using StringEntity.

> The main problem I had with understanding your NIO activities
> is now solved. I was always wondering how you were going to
> expose the channels at the entities so applications can use
> NIO features. From what I've seen now, you just don't.
> Applications continue to use blocking streams, which are then
> mapped to channels. Doesn't that mean that the context switches
> you want to avoid are just moved from the general IO operations
> to the NIO receiver/transmitter?

I _may_ be wrong here, as I do not have any empirical data to back up
this claim with, but I _believe_ this approach nonetheless requires less
context switching. The worker threads are blocked waiting on a mutex
instead of a network socket. They will not be woken up just to see if
there is any incoming data available. 

Of course, this approach does not solve one thread per connection
problem, it merely mitigates it. HttpCore NIO is meant to be just a
foundation asynchronous services could be built upon.

Now the Evil Plan (TM) is to start working on a asynchronous version of
HttpService that decouples the process of receiving HTTP requests,
generating response content and sending off resultant HTTP responses
using a fixed pool of worker threads. I am not sure how exactly this is
going to work (if at all) but I want to keep this idea on the back
burner for some while.



> cheers,
>   Roland
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org

To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org

View raw message