Mailing-List: contact httpclient-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient Project" <httpclient-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=GBixn6W5TbZOi8HcNvvD2EZuUimtGqcUlpPrZbWbPce0nHWIVDFIPrrfCqHLsVUSLOppgCxaUMiEIHrTlz2Df+MmLxOEiwdUKMFtBggHEM/k41NPkpg/+2r5OXlkyzRDe3OM0b5JP8QUyzttzbMApd0VWKbD8+3+TpizO+fzvCE=
  ;
Message-ID: <20060829053329.9131.qmail@web32809.mail.mud.yahoo.com>
Date: Mon, 28 Aug 2006 22:33:29 -0700 (PDT)
From: Tatu Saloranta <cowtowncoder@yahoo.com>
Subject: Re: [HttpCore] NIO extensions: progress report
To: HttpClient Project <httpclient-dev@jakarta.apache.org>
In-Reply-To: <1156805050.4935.20.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

--- Oleg Kalnichevski <olegk@apache.org> 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: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org