directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject Re: [seda] A preview on redesigned SEDA (or Netty?)
Date Wed, 08 Dec 2004 23:40:01 GMT

> I'm used to the SEDA style event model, and I'm not really straying that
> far from
> it.  However, I am optimizing on certain event types in the sense that I
> am not
> introducing new events when the events that are generated from NIO will
> work.
> I'm also streamlining things a bit in the sense of each stage does one
> thing, and
> does it well--which is supposed to be its strength.

That's good.  But 'events' in original SEDA was just a message in a
pipeline, and broadcasting events using EventRouters will not be good
for your health.

> The thread management for the SEDA environment I am creating is
> configurable.
> It can be only one thread, or it can be a proportion of threads to the
> number of
> processors, or it can be something much more complex (with multiple thread
> pools, etc.).  The library I am using already has a ThreadManager and a
> couple
> ThreadPolicies written.

In MINA, thread manager is optional.  It is just a part of
architecture.  Of course thread manager is important, but it is just
another implementation of SessionHandler or ProtocolSessionHandler
which decorates the original SessionHAndler or ProtocolSessionHandler.

> I was thinking that the ProtocolHandler wrapper doesn't really care how
> things
> are going under the scenes, but if they wanted they could have a simple
> way of
> adjusting it.
> For example, the SEDAServer is pretty much hard-coded in the sense that
> the pipelines are set up.  You can adjust things in this manner:
> // Yes its a singleton, but for good reason
> SEDAServer server = SEDAServer.getServer();
> Firewall firewall = server.getFirewall();
> firewall.deny(InetSocketAddress("", 6666);
> server.addProtocol( 8080, new HTTPProtocolHandler() );
> // (And things would just work)
> server.removeProtocol( 8080 );
> // (And it is now uninstalled )
> Now, if the user wanted to adjust the threadpolicy, I could
> enable something like this:
> SEDAServer.getServer().installPolicy(new SingleThreadPolicy());
> That would stop the old ThreadManager, and restart everything with
> the new thread policy.  Of course I can add some protections around it
> as well.

What you're talking about is just a counterexample for very simplistic
example of decoration.  We can create FirewallDecorator or
ThreadManager which can do the same thing in runtime.  The only
difference is that MINA doesn't try to integrate all of them to core
package.  Those are just decorations and optional.  Users will be able
to choose them, and some common features such as firewall and thread
manager would be able to be provided as a default internal decorator
by frontend package (not core).

Trustin Lee
what we call human nature is actually human habit

View raw message