You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Roland Weber <ht...@dubioso.net> on 2006/09/03 09:21:53 UTC
Re: [HttpCore] NIO extensions (first take) are ready for review
Hi Oleg,
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 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 will have to update build files so that the examples are
compiled and javadoced.
- 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.
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?
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpCore] NIO extensions (first take) are ready for review
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
> 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.
Ok, then it is just the example which I don't like :-)
> 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.
Sounds pretty much like what I'm heading to on the client side with
HttpDispatcher. Sooner or later (I'm afraid later) I'll reach the
point where I have to look into NIO in order to avoid having one
worker thread per connection just to detect incoming responses.
Lifting NIO up to the API itself would probably require rewriting
half of HttpCore. There's no point in thinking about that until we
have much more contributors.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpCore] NIO extensions (first take) are ready for review
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
Oleg
> 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