channels in James?

["Richard O. Hammer" <RO...@EarthLink.net>]

What is the status of the possibility of using java.nio.channels in James?

I have started to read about this package.  It looks like it might 
have benefits for James or a project like James.  In particular it 
seems to promise:
1) that blocked I/O operations on server Sockets can be interrupted 
gracefully
2) built in multi threading of connections
3) fancy buffering, somehow more efficient for large traffic

But I bet some people on this list have already studied it more than 
I, and formed valuable opinions.  I'd like to learn those opinions.

Thank you,
Rich Hammer


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

Re: channels in James?

[Serge Knystautas <se...@lokitech.com>]

Richard O. Hammer wrote:
> What is the status of the possibility of using java.nio.channels in James?
> 
> I have started to read about this package.  It looks like it might have 
> benefits for James or a project like James.  In particular it seems to 
> promise:
> 1) that blocked I/O operations on server Sockets can be interrupted 
> gracefully
> 2) built in multi threading of connections
> 3) fancy buffering, somehow more efficient for large traffic
> 
> But I bet some people on this list have already studied it more than I, 
> and formed valuable opinions.  I'd like to learn those opinions.

java.nio has very little use unless you have an application where 
connections are kept open but data isn't being sent.  HTTP, SMTP, and 
most common Internet protocols don't get much if any benefit from it. 
The biggest class of applications to benefit from java.nio is chat/IM 
where you have little data transfer and lots of open connections.

It would require a lot of rework to have the protocol handlers adjust to 
this, and this would only address the incoming connections, not the 
outgoing ones.  We use standard libs for the outgoing ones, so we'd have 
to start at ground zero with those.

Basically, it's not worth it... just a technology that was overhyped 
(something related to Java was overhyped?  impossible!) ;)

-- 
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: channels in James?

["Noel J. Bergman" <no...@devtech.com>]

Richard,

java.nio is certainly in the plans for James v3 (or later).  I've sketched
out what it will take.  Basically it involves completing an inversion inside
the handlers.  Each time data arrives, a dispatcher figures out for whom the
data is for, and dispatches it.  Switching over to 100% push processing,
instead of pull processing, is the key to java.nio.

I've devised a scheme were depending upon the state a Handler is in, a
Method is registered for handling the data.  In the command state, that
Method aggregates data until CRLF, then dispatches to the correct handling
method.  In the data state, the registered Method (a different one), keeps
feeding the data into a new method that will replace the pull-processing
inside of methods like doDATA.  The handler state has to be encapsulated in
its instance data.  The current code is not too bad, in terms of what it
will take to finish inverting it.  Most of the code is ready, but the
remaining portion epitomizes the 80%/20% rule.  :-)

It should be understood that java.nio is about the number of connections,
not about performance (although there are performance benefits).  Also,
java.nio doesn't support SSL.  I believe that Mark expects to support SSL in
Java 1.5.

So far we haven't had that much demand.  I say that based upon the fact that
we've had only one user raise the issue related to thread exhaustion, which
is controlled in v2.2.0aX.  So, as Serge says, this is not a high priority
right now, although I do believe that we'll want to deal with it in the
James v3 timeframe.

> 1) that blocked I/O operations on server Sockets can be interrupted
>    gracefully

> 2) built in multi threading of connections

Not quite "built-in".  Yes, it is built-in, but that is because of how you
have to use it, not because they provide something for free.

> 3) fancy buffering, somehow more efficient for large traffic

Yes, nio provides much better buffering controls.

	--- Noel


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