You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by typedef_lex <co...@chello.at> on 2003/04/28 20:41:38 UTC
Async I/O
Hi,
are there plans to rewrite James, so it can benefit from the "new" asynchronous I/O classes?
The asserted improvment seems to deserve a catch up.
typedef_lex
Re: Async I/O
Posted by Serge Knystautas <se...@lokitech.com>.
typedef_lex wrote:
> Hi,
>
> are there plans to rewrite James, so it can benefit from the "new"
> asynchronous I/O classes?
> The asserted improvment seems to deserve a catch up.
>
> typedef_lex
Well, this is up to the good folks at Avalon since we use their server
framework.
But very few server implementors I know have cared much about this API
addition, at least not in the HTTP server space. With an app that
maintains hundreds or thousands of open connections (like chat/IM), then
it would be useful. I don't think SMTP would benefit for the same
reason that HTTP doesn't... just not enough open connections.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Async I/O
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>> it might be not necessary in most cases, but it would be
>> a nice label to put on, especially regarding the image
>> factor of the java performance. As far as i know the
>> amount of work wouldnt be considerable.
>
>
> Supporting NIO requires rewriting James' connection handlers. With java.io,
> each connection is represented by a socket with a thread dedicated to
> processing that connection for its duration. With java.nio, you have a
> thread checking for selectors with available data, then you use a worker to
> handle the data. These non-dedicated threads handle just the available data
> and return immediately. You have to restructure how you maintain connection
> state. For the most part, the handlers are well structured for the change,
> except for a command like SMTP DATA. Also, NIO doesn't support SSL, nor is
> expected to prior to JDK 1.5, so java.io is still necessary. Therefore NIO
> support is not a high priority at this time.
Yeah, actually was going to say, it's a lot of work to change. The way
you handle input and output changes substantially (as Noel describes).
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Async I/O
Posted by "Noel J. Bergman" <no...@devtech.com>.
> it might be not necessary in most cases, but it would be
> a nice label to put on, especially regarding the image
> factor of the java performance. As far as i know the
> amount of work wouldnt be considerable.
Normal I/O performance of James is actually pretty good. This is not a
surprise, since the primary benefit of NIO relates to scalability, i.e., the
number of simultaneous connections, and per connection resources. If you
are interested in the influence of NIO on application scalability and
performance, you should look for a study by Mark Reinhold on the subject.
Supporting NIO requires rewriting James' connection handlers. With java.io,
each connection is represented by a socket with a thread dedicated to
processing that connection for its duration. With java.nio, you have a
thread checking for selectors with available data, then you use a worker to
handle the data. These non-dedicated threads handle just the available data
and return immediately. You have to restructure how you maintain connection
state. For the most part, the handlers are well structured for the change,
except for a command like SMTP DATA. Also, NIO doesn't support SSL, nor is
expected to prior to JDK 1.5, so java.io is still necessary. Therefore NIO
support is not a high priority at this time.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Async I/O
Posted by typedef_lex <co...@chello.at>.
As Serge Knystautas stated, it might be not necessary in most cases, but it
would be a nice label to put on, especially regarding the image factor of
the java performance. As far as i know the amount of work wouldnt be
considerable.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Monday, April 28, 2003 9:03 PM
Subject: RE: Async I/O
> > are there plans to rewrite James, so it can benefit from
> > the "new" asynchronous I/O classes?
>
> Eventually. The changes necessary are fairly well understood.
>
> > The asserted improvment seems to deserve a catch up.
>
> Actually, that depends. The real benefit is the ability to handle large
> numbers of connections with a smaller number of threads.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Async I/O
Posted by "Noel J. Bergman" <no...@devtech.com>.
> are there plans to rewrite James, so it can benefit from
> the "new" asynchronous I/O classes?
Eventually. The changes necessary are fairly well understood.
> The asserted improvment seems to deserve a catch up.
Actually, that depends. The real benefit is the ability to handle large
numbers of connections with a smaller number of threads.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org