You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Trustin Lee <tr...@gmail.com> on 2007/04/05 07:23:01 UTC

SocketAcceptor.Worker + SocketIoProcessor.Worker?

Hi guys,

For now, there are two kinds of workers in MINA TCP/IP transport
implementation.  One is the acceptor, and the other is the socket I/O
processor.

The acceptor thread accepts incoming connections and forward them to
the socket I/O processor.  It is working very stable, but this
separation is causing high latency for protocols that establish a
connection per request (e.g. HTTP without keep-alive).

We might be able to fix this issue by merging an acceptor thread and
I/O processor thread, that is, one thread could accept incoming
connections and perform read and write operations.  Plus, this means
more than one thread will accept incoming connections when the number
of I/O processor threads increases, like it does for read and write
operations.

Of course, we need to run some performance test before we check this
change into trunk.  Also, please let me know one's experience if
there's anyone who tried to implement a NIO server in this manner.

Thanks,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: SocketAcceptor.Worker + SocketIoProcessor.Worker?

Posted by peter royal <pr...@apache.org>.
On Apr 4, 2007, at 10:23 PM, Trustin Lee wrote:
> We might be able to fix this issue by merging an acceptor thread and
> I/O processor thread, that is, one thread could accept incoming
> connections and perform read and write operations.  Plus, this means
> more than one thread will accept incoming connections when the number
> of I/O processor threads increases, like it does for read and write
> operations.

Have you run any tests with this? What if accepting connections was a  
task the various reader threads could share? When a thread is ready  
to go back to listening for reads, it can see if anyone is listening  
for connections, and if not, it also listens for connection events.  
That way we could still have multiple IO threads, and accept  
connections from them directly as well..

-pete


-- 
proyal@apache.org - http://fotap.org/~osi




Re: SocketAcceptor.Worker + SocketIoProcessor.Worker?

Posted by "Steven E. Harris" <se...@panix.com>.
Trustin Lee <tr...@gmail.com> writes:

> Of course, we need to run some performance test before we check this
> change into trunk.  Also, please let me know one's experience if
> there's anyone who tried to implement a NIO server in this manner.

I attended a talk at SDWest by Ron Hitchens¹ on NIO where he addressed
this topic. On page 23 of his slides², he mentions that in his own
framework built on NIO, he separates out accepting connections from
the rest of the dispatching. He didn't offer much detail on this, and
my notes don't have anything beyond the text of that particular slide,
but I recall him saying something about dedicating a thread to
accepting connections -- just like MINA does (or did) today.

I asked Mr. Hitchens if he had heard of MINA. He said yes, he had
heard of it, but had not had time to look at in detail yet. Perhaps
he'd be willing to share his insight on this design question.


Footnotes: 
¹ http://javanio.info/
² http://ronsoft.net/files/NIOServer.pdf

-- 
Steven E. Harris