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: domain of robo@khelekore.org designates
 82.182.181.242 as permitted sender)
Message-ID: <44F476D3.50008@khelekore.org>
Date: Tue, 29 Aug 2006 19:18:11 +0200
From: Robert Olofsson <robo@khelekore.org>
User-Agent: Thunderbird 1.5.0.5 (X11/20060728)
MIME-Version: 1.0
To: HttpClient Project <httpclient-dev@jakarta.apache.org>
Subject: Re: [HttpCore] NIO extensions: progress report
References: <20060829053329.9131.qmail@web32809.mail.mud.yahoo.com>
In-Reply-To: <20060829053329.9131.qmail@web32809.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tatu Saloranta wrote:
> 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.

A single worker thread is very hard to have with current java.
There are too many blocking operations in the standard api
and that some things like FileInputStream/FileChannel
are not SelectableChannels does not make it easier.

One example: InetAddress may, depending on jvm/host,
be jni-single threaded. That means that jvm can
only do one dns lookup at a time. Not very nice
for a http proxy that needs to do many concurrent
lookups, many who may be bogous. The dnsjava
package solved that for me, but library is still
threaded so I still need worker threads..

So even if you use NIO you probably want to keep
worker threads for file access, for db access, for
dns lookup, ... Exactly how many workers you need
depend very much on what you do.

Using a nio library correctly is not easy, unless the library
always uses worker threads whenever a channel is ready.

> 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. 

Many people say that nio has higher overhead, I am not
sure how much that is true, there is less context switches
and direct buffers can give zero copy, which for some
operations is very nice (http proxy again). Running a
single selector thread also means that no operations need
synchronization.
Still this is not easy to do with current api.

Do you have any benchmarks?

>> Benefits of NIO on the
>> client side seem lesser than on the server side. 

Depends on what you do, but most clients only keep a few
connections open at once so threaded io is just as easy.

For me nio vs threaded io is more a question of style.
NIO is more event based programming.

> documented at wiki pages) can lead to significant
> improvements to scalability over existing http
> solutions, 

Just curious, what existing http solutions have you looked at?
There are lots of threaded http solutions and a few
that use nio.

/robo


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