Re: Re[2]: [Nbserver-devel] NBServer for "client" side ...

[Attila S. <sze...@fr...>]

----- Original Message -----
From: "Zombi" <zo...@ma...>
To: "Attila Szegedi" <sze...@fr...>
Sent: Wednesday, February 27, 2002 10:50 PM
Subject: Re[2]: [Nbserver-devel] NBServer for "client" side ...


>
> > Take a look and tell me how do you like it. Note that in the current
> > scenario the user has to create the socket channel, but it is OK - he
might
> > want to set different TCP options on the socket (linger, timeout,
nodelay,
> > etc.) and I don't want to take away that flexibility.
>
>  Well... your code is much simpler, and easier to use, so I like it :-)
> Thx for the credits :-)
> Anyway ... what's your future plans about the whole package ? to
> create a small and simple web server? or an adapter for
> Tomcat/Catalina?

Well, it started as my learning ground for non-blocking I/O in Java... I
thought it'd be a good idea to write an in-depth "best practices" style
article on the topic, so I needed to familiarize myself with it.
There really is a generic HTTP handler in the source tree, and with various
Adapter implementations, it can be fitted onto Tomcat, or serve as a base
for a standalone HTTP server, so there is a goal of creating a non-blocking
frontend to Tomcat, indeed.

The more I think of it, the more I realize that it has to be refactored
heavily. First, selector threads should not run protocol handler code.
Instead, they should queue OP_whatever events (in a LinkedList, say) and a
separate pool of worker threads should get events from the queue and process
them one by one. This decoupling of a connection and worker thread would
provide for better work balance between threads, and in the end better
throughput (right now, if some protocol handler takes a long time to
complete, all other protocol handlers registered with the same selector
thread are waiting). Next, there should be some other entity, a thread
manager that increases/decreases the number of worker threads as the queue
latency grows/decreases. The concept could be expanded toward generic event
queues and a thread manager that dynamically allocates event processing
threads from faster queues to slower queues. With my thoughts going in that
direction, we're starting to suspiciously look like Matt Welsh's SEDA, whose
complexity I was trying to avoid... In the end, maybe the guy was right and
that's the minimum complexity required for a truly performant NBIO server?
I'm devoting some more thinking to it; we'll see.

Cheers,
  Attila.

P.S.: Are you aware that SourceForge mailing lists are set up so that
"Reply" sends a reply to the poster, not to the list? I'm asking since your
letter came to me privately, not through the list.

>
> bye
>    Zsombor
>
>
>
>