You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Trustin Lee <tr...@gmail.com> on 2004/12/04 14:00:35 UTC
[seda] A preview on redesigned SEDA (or Netty?)
Hi.
I'm implemented basic Echo protocol server using new API and
architecture. You can browse the architecture at:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=directory-dev@incubator.apache.org&msgId=2020833
and the API and implementation in progress at:
http://svn.apache.org/viewcvs.cgi/incubator/directory/seda/branches/trustin/
Please look at Echo server implementation at:
http://svn.apache.org/viewcvs.cgi/incubator/directory/seda/branches/trustin/src/examples/org/apache/netty/examples/echo/server/
I hope you guys like this! Any critiques or suggestions are appreciated. :)
Currently minimal TCP downstream implementation is available, but I
expect I can implement all part of downstream layer soon.
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Trustin Lee wrote:
<snip/>
>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).
>
>
I really like this optional feature thingy btw. Decorations are very
cool for extending behavoir.
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Berin Loritsch <bl...@d-haven.org>.
Trustin Lee wrote:
>Hi.
>
>
>
>>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.
>
>
I only have one router, which maps events that belong to one port to the
appropriate
pipeline for protocol handling. It's not too different from what MINA
does--except
for the mechanism. In essence, you do have a way of routing traffic on
port 6666 to
the proper protocol handler.
Of course, I can change the mechanism and add an attachment to the
selector so that
the proper pipeline is attached to the selectionkey when it is ready.
Hmmm. That might
be a better way to implement the routing. Nevertheless something of
that sort needs to
be there--the mechanisms might differ.
>>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 see.
>>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("127.0.0.1", 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).
>
>
>
:) Of course, there needs to be a way to add deny/allow settings to the
Firewall at
runtime. So far I am keeping things simple--at least in my mind. I
think the core
difference here is that MINA relies on decorators while SEDA
accomplishes something
similar using stages to transform events as necessary.
Two different concepts regarding network programming. And it is
perfectly fine to
explore them both. In fact, in this case I think it will be very
beneficial. As Alex
said, having two different networking libraries might be something where
the end user
can pick what they want to tune their server for the demands that they have.
--
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Trustin Lee <tr...@gmail.com>.
Hi.
> 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("127.0.0.1", 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).
Cheers,
Trustin Lee
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Richard Wallace <rw...@thewallacepack.net>.
Alex Karasulu wrote:
> Yeah I think Berin's stuff is going to be closest to what we have in the
> trunk of SEDA. I think MINA was more a thing that should have gone into
> a sandbox. There is no reason to have it in a branch when it is not the
> same thing that cannot merge back. Anyway let's see what happens when
> we bang against these servers. If you go with SEDA in the trunk today
> I don't think switching to Berin's new rendition of SEDA (which usess
> the d-haven event packages) will be hard when it is done.
>
> I'd like to see what the performance curves are for these
> implementations using Eve with search operations as we increase the
> number of concurrent connections and requests.
> Alex
>
Sounds like a plan. This is how I'll procede then. Thanks for the
feedback.
Rich
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Richard Wallace wrote:
> Alex Karasulu wrote:
>
>> Richard Wallace wrote:
>>
>>> Alex Karasulu wrote:
>>
>>
<snip/>
>>
>> Actually the parse part is the "decode" stage. The stateful
>> (chunking) encoder decoder pair will do this for you. This is why
>> the ProtocolProvider has a getEncoderFacotry() and a
>> getDecoderFactory() method defined. Regulating these operations with
>> a stage makes sense under load. Sometimes you'll have encodings that
>> are CPU intensive and so you need a higher ratio of threads to load.
>> SEDA is excellent for that. Somethimes the encoding is a joke. In
>> this case I'd like to make it so the provider could somehow tell SEDA
>> to skip encoding or decoding stages to not suffer synchronization
>> penalties and latency costs.
>>
>
> Oh I see. I hadn't seen the getEncoderFactory() and
> getDecoderFactory() before. I agree that in the decoding stage you
> could do the parsing part and in most scenarios that is probably what
> you want to do. But I can see cases where you may want to have more
> stages for doing things like (en|de)cryption, (un)compression, etc.
> But then, for those that want/need something like this, they can have
> their encoder/decoder factories build little sub-pipelines that do that.
>
Right exactly. The Kerberos server may have to do this because it
encodes PDUs inside encrypted ASN.1 PDUs. Hairy little protocol ain't
it. I'm sure there are several exceptions like this that make you point
valid.
<snip/>
>>
>> Funny you say this Trustin and I were talking last night about this.
>> I think he rights some bullet proof code and his abstractions for
>> handing non-blocking IO are really really nice. But this is not
>> SEDA. Berin touched on this too and talked about the possibility of
>> a hybrid. Perhaps we just need more than one choice or just that a
>> hybrid that uses one over the other until certail thresholds are
>> reached.
>
>
> Now that really would be awesome! The tough thing is figuring out
> those thresholds. But that's a bit OT right now.
>
That's fun testing and sysadmin tuning stuff. Love to get there some day.
<snip/>
>> Exactly! Well said. Take a look at the CoR stuff and the
>> commons-pipeline effort over at Jakarta. They have been doing
>> similar things perhaps better for network specific and general
>> applications that are processing anything like images in the example
>> you gave above. Please let us know what you think. Your grip on
>> SEDA and its merits is pretty solid and well I have been trying to
>> understand the SEDA commons-pipline connection to no avail. Looking
>> forward to your impressions and comments....
>
<snip/>
> I'm not sure what you mean by a connection between commons-pipeline
> and SEDA. The concepts are fundamentally the same. There is are
> pipelines and within pipelines are stages and the stages processing is
> controlled by what in c-p is a "StageDriver" and in SEDA is a
> Controller with a thread pool. Right now it looks like c-p only has a
> SingleThreadStageDriver, but it wouldn't be difficult to add a
> StageDriver that uses a thread pool, I don't think.
Sounds very similar to what we have.
> The biggest feature that they are currently missing that is in the
> directory seda implementation is event routing.
Funny you and Trustin both see that as a strength. Trustin sees that as
a weakness. I can go both ways.
> From what I've seen in the directory seda code an Event can be routed
> to one or more (? it looks like right now DefaultEventRouter throws an
> UnsupportedOperationException, on line 148, if this situation occurs,
> but the framework is there to support such a thing) different stages.
> Right now the c-p pipeline just passes events from one stage to the
> next in the order that the stages were added. There is support for
> doing a branch to another pipeline, though it's not clear when this
> branch is taken.
>
> I think the framework in directory is much more complete and usable.
Yeah I think its really easy to use because the complex rarly used
concepts are left out for you to implement. You only need a little bit
of SEDA concepts to wreak 90% of its power. I've always wanted to keep
it simple:
Stage = ThreadPool + Queue + EnquePredicates + (Work) Driver
It's that simple to me. Also the event router / bus pattern which I
stole from Berin I might add decouples stages. This is excellent for
dyamically assembing stages or creating stages that process different
aspects of an event that need not synchronize by routing them to more
than one stage. There's lots of fancy things we could do but until we
get a chance to test out the basic with real protocols we'll never know
for sure.
One of my main goals is to get something really simple writen to test.
Then take that and build a real protocol server I can bang against.
Until then everything sounds good in theory. So I built this simple
SEDA thing and it works but may not be anything but an experiment.
That's why I was not against having multiple implementations going on at
the same time in the seda project who knows what we're going to discover.
> If it turns out that I can't use it for the sub-pipelines I need that
> we talked about before then I'll probably just use Berin's d-haven
> event package to build my own pipeline for processing. Might not be
> pretty but I think I could make something that would work for my
> purposes. I don't think I'll need to do that tho, not from what I've
> seen so far.
Yeah I think Berin's stuff is going to be closest to what we have in the
trunk of SEDA. I think MINA was more a thing that should have gone into
a sandbox. There is no reason to have it in a branch when it is not the
same thing that cannot merge back. Anyway let's see what happens when
we bang against these servers. If you go with SEDA in the trunk today
I don't think switching to Berin's new rendition of SEDA (which usess
the d-haven event packages) will be hard when it is done.
I'd like to see what the performance curves are for these
implementations using Eve with search operations as we increase the
number of concurrent connections and requests.
Alex
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Richard Wallace <rw...@thewallacepack.net>.
Alex Karasulu wrote:
> Richard Wallace wrote:
>
>> Alex Karasulu wrote:
>
>
> <snip/>
>
>>
>>>
>>> Yep that's my primary concern with any API and the heart of the
>>> framework. Basically you have the common plumbing in place
>>> (input,decode,process,encode,output). Using the same stage component
>>> for the stages in this prefab pipeline you should be able to build
>>> your own pipelines inside the ProtoPro.
>>>
>>
>> Alright, that's kind of what I was thinking. Because servers also
>> typically need to access some kind of backing store at some point.
>> For some things, like a DNS server, this could easily be done in a one
>> step, but for something like a web server or email server this could
>> be a multi-step process, or need to be asynchronous itself, such as
>> when doing file IO. I would think that even an LDAP server could
>> benefit from more than one stage in the protocol handling because
>> you've got to parse the incoming request and turn it into something
>> that you can easily pass to your backend.
>
>
> Actually the parse part is the "decode" stage. The stateful (chunking)
> encoder decoder pair will do this for you. This is why the
> ProtocolProvider has a getEncoderFacotry() and a getDecoderFactory()
> method defined. Regulating these operations with a stage makes sense
> under load. Sometimes you'll have encodings that are CPU intensive and
> so you need a higher ratio of threads to load. SEDA is excellent for
> that. Somethimes the encoding is a joke. In this case I'd like to make
> it so the provider could somehow tell SEDA to skip encoding or decoding
> stages to not suffer synchronization penalties and latency costs.
>
Oh I see. I hadn't seen the getEncoderFactory() and getDecoderFactory()
before. I agree that in the decoding stage you could do the parsing
part and in most scenarios that is probably what you want to do. But I
can see cases where you may want to have more stages for doing things
like (en|de)cryption, (un)compression, etc. But then, for those that
want/need something like this, they can have their encoder/decoder
factories build little sub-pipelines that do that.
>> Then I would think that whatever backend your using, you would want
>> that to be an asynchronous request (especially in the case where your
>> backend is another ldap server or something else that could have a
>> high latency).
>>
> Good call on application of this. Yes this would be a good example for it.
>
I forgot file IO. That's a biggie in web and mail servers.
>> I see your point that you want to make it as simple as possible and
>> I'm all for that. I've looked at the DefaultFrontend and
>> DefaultFrontendFactory in the seda trunk and it does seem like it is
>> be easy to build new and varied pipelines with it. I just wanted to
>> ask because while looking through Mina I got the feeling that it is
>> mostly just concerned with abstracting the details of asynchronous
>> network IO away from the developer and not necessarily processing
>> requests in a pipeline.
>
>
> Funny you say this Trustin and I were talking last night about this. I
> think he rights some bullet proof code and his abstractions for handing
> non-blocking IO are really really nice. But this is not SEDA. Berin
> touched on this too and talked about the possibility of a hybrid.
> Perhaps we just need more than one choice or just that a hybrid that
> uses one over the other until certail thresholds are reached.
Now that really would be awesome! The tough thing is figuring out those
thresholds. But that's a bit OT right now.
> now MINA will blow away any SEDA implementation up until I think 100s of
> clients. Then SEDA is your savior.
> Now MINA is more ACE/Netty like which is great. And SEDA well is SEDA
> which is great too. In the end I want these frameworks to be sooo easy
> to use protocol implementors do not need swim in SEDA or ACE or NIO. I
> want to think about requests and responses. This ease of use and
> performance in all scenarios are my two big requirements.
>
Sounds good to me. =)
>> To me that the core of what SEDA is all about, not just asynchronous
>> IO, but asynchronous event processing. Whether those events are
>> network operations, operations to perform on an image or some other
>> form of user input.
>
>
> Exactly! Well said. Take a look at the CoR stuff and the
> commons-pipeline effort over at Jakarta. They have been doing similar
> things perhaps better for network specific and general applications that
> are processing anything like images in the example you gave above.
> Please let us know what you think. Your grip on SEDA and its merits is
> pretty solid and well I have been trying to understand the SEDA
> commons-pipline connection to no avail. Looking forward to your
> impressions and comments....
>
I hadn't seen the commons-pipeline project before but I'm always a bit
wary of stuff in the commons. Here's a good example of why (found in
the DigesterPipelineFactory.init() method):
ruleSets.add(new PipelineRuleSet(ruleSets));
Aside from that hesitation to use anything commons related (which is
nearly unavoidable these days it seems). I'm not sure what you mean by a
connection between commons-pipeline and SEDA. The concepts are
fundamentally the same. There is are pipelines and within pipelines are
stages and the stages processing is controlled by what in c-p is a
"StageDriver" and in SEDA is a Controller with a thread pool. Right now
it looks like c-p only has a SingleThreadStageDriver, but it wouldn't be
difficult to add a StageDriver that uses a thread pool, I don't think.
The biggest feature that they are currently missing that is in the
directory seda implementation is event routing. From what I've seen in
the directory seda code an Event can be routed to one or more (? it
looks like right now DefaultEventRouter throws an
UnsupportedOperationException, on line 148, if this situation occurs,
but the framework is there to support such a thing) different stages.
Right now the c-p pipeline just passes events from one stage to the next
in the order that the stages were added. There is support for doing a
branch to another pipeline, though it's not clear when this branch is taken.
I think the framework in directory is much more complete and usable. If
it turns out that I can't use it for the sub-pipelines I need that we
talked about before then I'll probably just use Berin's d-haven event
package to build my own pipeline for processing. Might not be pretty
but I think I could make something that would work for my purposes. I
don't think I'll need to do that tho, not from what I've seen so far.
Rich
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Richard Wallace wrote:
> Alex Karasulu wrote:
<snip/>
>
>>
>> Yep that's my primary concern with any API and the heart of the
>> framework. Basically you have the common plumbing in place
>> (input,decode,process,encode,output). Using the same stage component
>> for the stages in this prefab pipeline you should be able to build
>> your own pipelines inside the ProtoPro.
>>
>
> Alright, that's kind of what I was thinking. Because servers also
> typically need to access some kind of backing store at some point.
> For some things, like a DNS server, this could easily be done in a one
> step, but for something like a web server or email server this could
> be a multi-step process, or need to be asynchronous itself, such as
> when doing file IO. I would think that even an LDAP server could
> benefit from more than one stage in the protocol handling because
> you've got to parse the incoming request and turn it into something
> that you can easily pass to your backend.
Actually the parse part is the "decode" stage. The stateful (chunking)
encoder decoder pair will do this for you. This is why the
ProtocolProvider has a getEncoderFacotry() and a getDecoderFactory()
method defined. Regulating these operations with a stage makes sense
under load. Sometimes you'll have encodings that are CPU intensive and
so you need a higher ratio of threads to load. SEDA is excellent for
that. Somethimes the encoding is a joke. In this case I'd like to make
it so the provider could somehow tell SEDA to skip encoding or decoding
stages to not suffer synchronization penalties and latency costs.
> Then I would think that whatever backend your using, you would want
> that to be an asynchronous request (especially in the case where your
> backend is another ldap server or something else that could have a
> high latency).
>
Good call on application of this. Yes this would be a good example for it.
> I see your point that you want to make it as simple as possible and
> I'm all for that. I've looked at the DefaultFrontend and
> DefaultFrontendFactory in the seda trunk and it does seem like it is
> be easy to build new and varied pipelines with it. I just wanted to
> ask because while looking through Mina I got the feeling that it is
> mostly just concerned with abstracting the details of asynchronous
> network IO away from the developer and not necessarily processing
> requests in a pipeline.
Funny you say this Trustin and I were talking last night about this. I
think he rights some bullet proof code and his abstractions for handing
non-blocking IO are really really nice. But this is not SEDA. Berin
touched on this too and talked about the possibility of a hybrid.
Perhaps we just need more than one choice or just that a hybrid that
uses one over the other until certail thresholds are reached. Cuz right
now MINA will blow away any SEDA implementation up until I think 100s of
clients. Then SEDA is your savior.
Now MINA is more ACE/Netty like which is great. And SEDA well is SEDA
which is great too. In the end I want these frameworks to be sooo easy
to use protocol implementors do not need swim in SEDA or ACE or NIO. I
want to think about requests and responses. This ease of use and
performance in all scenarios are my two big requirements.
> To me that the core of what SEDA is all about, not just asynchronous
> IO, but asynchronous event processing. Whether those events are
> network operations, operations to perform on an image or some other
> form of user input.
Exactly! Well said. Take a look at the CoR stuff and the
commons-pipeline effort over at Jakarta. They have been doing similar
things perhaps better for network specific and general applications that
are processing anything like images in the example you gave above.
Please let us know what you think. Your grip on SEDA and its merits is
pretty solid and well I have been trying to understand the SEDA
commons-pipline connection to no avail. Looking forward to your
impressions and comments....
Cheers,
Alex
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Richard Wallace <rw...@thewallacepack.net>.
Alex Karasulu wrote:
> Richard Wallace wrote:
>
>> Hey guys,
>>
>> I'd like to chime in if I might. A network admin friend and I have
>> decided to write a mail server in Java in our spare time, just for the
>> fun of it. I'm eager to play with using SEDA to handle the flow of
>> operations, and was hoping I could use the SEDA library in this
>> project as the basis for that.
>>
> Coolio!
>
>> I'm a little confused on what you guys are discussing right now, tho.
>> Most of what you seem to be talking about sounds like a pipeline with
>> a fixed number of stages in it.
>
>
> Right.
>
>> The reason I say this is because of the ProtocolHandler class. It
>> seems to me that you would also want to break up the ProtocolHandler
>> into different stages.
>
>
> Yeah we could do that but the way this would be done would be very
> specific to the nature of the protocol server. Some servers I'm sure
> would be very conducive to it. We could write a really generalized
> framework for that but one exists in commons called commons pipeline for
> managing logical stages. However by sticking to handling the network
> plumbing aspects and creating a demarcation at the point of the
> ProtocolProvider allows the SEDA framework to keep its focus wrt
> networking aspects of the server. This makes for a better framework.
> The more general a framework gets the less useful it usually becomes IMHO.
>
>>
>> For instance, in Matt Welsh's http server, Haboob, he had several
>> stages dealing with cache and file IO and dynamic page generation. I
>> plan on looking to do something similar in the mail server my friend
>> and I are getting ready to write.
>
>
> That's cool let use know where you're doing this.
>
ATM we're just going to self host our code. Once we get a little bit
more going and have decided that it's something we want to continue
we'll probably start a SF project. After that, we'd like to try and get
into apache, if there is interest.
>> I'm curious how this type of ProtocolHandler would be constructed in
>> Mina and Berin's SEDA implementation (I can't wait to see more code
>> there).
>
>
> With the present SEDA implementation you can use the stages to build
> your own pipeline within the ProtoPro easily and that's up to u. With
> the common plumbing of several inet servers having an input, decode,
> process, encode and output stage we took the liberty of hard coding this
> outter pipeline. Nest into it below the ProtoPro as you like.
>
>> Would you need to build a sort of sub-pipeline within the protocol
>> handler to accomplish this?
>
>
> Just as I was describing above. You can do this with the SEDA platform
> I have been using in the trunk. I would imagine we could do the same if
> not better with the SEDA implementation Berin is working on.
>
>> I think it is very important that it is easy for someone to be able to
>> plug in a new ProtocolHandler and be able to take advantage of the
>> concurrency and scalability that the non-blocking IO and SEDA provide,
>> but it should also be fairly straightforward to build new pipelines.
>
>
> Yep that's my primary concern with any API and the heart of the
> framework. Basically you have the common plumbing in place
> (input,decode,process,encode,output). Using the same stage component
> for the stages in this prefab pipeline you should be able to build your
> own pipelines inside the ProtoPro.
>
Alright, that's kind of what I was thinking. Because servers also
typically need to access some kind of backing store at some point. For
some things, like a DNS server, this could easily be done in a one step,
but for something like a web server or email server this could be a
multi-step process, or need to be asynchronous itself, such as when
doing file IO. I would think that even an LDAP server could benefit
from more than one stage in the protocol handling because you've got to
parse the incoming request and turn it into something that you can
easily pass to your backend. Then I would think that whatever backend
your using, you would want that to be an asynchronous request
(especially in the case where your backend is another ldap server or
something else that could have a high latency).
I see your point that you want to make it as simple as possible and I'm
all for that. I've looked at the DefaultFrontend and
DefaultFrontendFactory in the seda trunk and it does seem like it is be
easy to build new and varied pipelines with it. I just wanted to ask
because while looking through Mina I got the feeling that it is mostly
just concerned with abstracting the details of asynchronous network IO
away from the developer and not necessarily processing requests in a
pipeline. To me that the core of what SEDA is all about, not just
asynchronous IO, but asynchronous event processing. Whether those
events are network operations, operations to perform on an image or some
other form of user input.
Rich
>>
>> Everything I've seen so far looks great. I'm eager to try this stuff
>> out in my own project.
>
>
> Both Trustin and Berin have some great ideas in addition to the SEDA
> framework we have in the trunk.
>
> Cheers,
> Alex
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Richard Wallace wrote:
> Hey guys,
>
> I'd like to chime in if I might. A network admin friend and I have
> decided to write a mail server in Java in our spare time, just for the
> fun of it. I'm eager to play with using SEDA to handle the flow of
> operations, and was hoping I could use the SEDA library in this
> project as the basis for that.
>
Coolio!
> I'm a little confused on what you guys are discussing right now, tho.
> Most of what you seem to be talking about sounds like a pipeline with
> a fixed number of stages in it.
Right.
> The reason I say this is because of the ProtocolHandler class. It
> seems to me that you would also want to break up the ProtocolHandler
> into different stages.
Yeah we could do that but the way this would be done would be very
specific to the nature of the protocol server. Some servers I'm sure
would be very conducive to it. We could write a really generalized
framework for that but one exists in commons called commons pipeline for
managing logical stages. However by sticking to handling the network
plumbing aspects and creating a demarcation at the point of the
ProtocolProvider allows the SEDA framework to keep its focus wrt
networking aspects of the server. This makes for a better framework.
The more general a framework gets the less useful it usually becomes IMHO.
>
> For instance, in Matt Welsh's http server, Haboob, he had several
> stages dealing with cache and file IO and dynamic page generation. I
> plan on looking to do something similar in the mail server my friend
> and I are getting ready to write.
That's cool let use know where you're doing this.
> I'm curious how this type of ProtocolHandler would be constructed in
> Mina and Berin's SEDA implementation (I can't wait to see more code
> there).
With the present SEDA implementation you can use the stages to build
your own pipeline within the ProtoPro easily and that's up to u. With
the common plumbing of several inet servers having an input, decode,
process, encode and output stage we took the liberty of hard coding this
outter pipeline. Nest into it below the ProtoPro as you like.
> Would you need to build a sort of sub-pipeline within the protocol
> handler to accomplish this?
Just as I was describing above. You can do this with the SEDA platform
I have been using in the trunk. I would imagine we could do the same if
not better with the SEDA implementation Berin is working on.
> I think it is very important that it is easy for someone to be able to
> plug in a new ProtocolHandler and be able to take advantage of the
> concurrency and scalability that the non-blocking IO and SEDA provide,
> but it should also be fairly straightforward to build new pipelines.
Yep that's my primary concern with any API and the heart of the
framework. Basically you have the common plumbing in place
(input,decode,process,encode,output). Using the same stage component
for the stages in this prefab pipeline you should be able to build your
own pipelines inside the ProtoPro.
>
> Everything I've seen so far looks great. I'm eager to try this stuff
> out in my own project.
Both Trustin and Berin have some great ideas in addition to the SEDA
framework we have in the trunk.
Cheers,
Alex
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Berin Loritsch <bl...@d-haven.org>.
Richard Wallace wrote:
> Hey guys,
>
> I'd like to chime in if I might. A network admin friend and I have
> decided to write a mail server in Java in our spare time, just for the
> fun of it. I'm eager to play with using SEDA to handle the flow of
> operations, and was hoping I could use the SEDA library in this
> project as the basis for that.
We are talking about two basic ways of attacking the same problem. We
are trying to come up with something that works,
but isn't too "frameworky" if you know what I mean.
> I'm a little confused on what you guys are discussing right now, tho.
> Most of what you seem to be talking about sounds like a pipeline with
> a fixed number of stages in it. The reason I say this is because of
> the ProtocolHandler class. It seems to me that you would also want to
> break up the ProtocolHandler into different stages.
This is true, but the ProtocolHandler can be broken up into different
stages without really knowing much about SEDA or MINA.
> For instance, in Matt Welsh's http server, Haboob, he had several
> stages dealing with cache and file IO and dynamic page generation. I
> plan on looking to do something similar in the mail server my friend
> and I are getting ready to write.
Yeah, but that is kind of beyond what we need. What we need is a
network interaction that is scalable for an LDAP server,
which is a simpler model than serving up HTTP pages.
> I'm curious how this type of ProtocolHandler would be constructed in
> Mina and Berin's SEDA implementation (I can't wait to see more code
> there). Would you need to build a sort of sub-pipeline within the
> protocol handler to accomplish this? I think it is very important
> that it is easy for someone to be able to plug in a new
> ProtocolHandler and be able to take advantage of the concurrency and
> scalability that the non-blocking IO and SEDA provide, but it should
> also be fairly straightforward to build new pipelines.
I think the concentration for both of us is to just be able to service
the LDAP/Eve/Kerberos implementation we have here. Adding more complex
pipelines is a bit beyond what we would like to address ATM. In the
future we would like to set up a protocol handler to set up a load
balancer--what would work fairly well with either framework we have set up.
> Everything I've seen so far looks great. I'm eager to try this stuff
> out in my own project.
You might be able to start playing with MINA. I'm not ready with the
simplified SEDA yet.
--
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Richard Wallace <rw...@thewallacepack.net>.
Hey guys,
I'd like to chime in if I might. A network admin friend and I have
decided to write a mail server in Java in our spare time, just for the
fun of it. I'm eager to play with using SEDA to handle the flow of
operations, and was hoping I could use the SEDA library in this project
as the basis for that.
I'm a little confused on what you guys are discussing right now, tho.
Most of what you seem to be talking about sounds like a pipeline with a
fixed number of stages in it. The reason I say this is because of the
ProtocolHandler class. It seems to me that you would also want to break
up the ProtocolHandler into different stages.
For instance, in Matt Welsh's http server, Haboob, he had several stages
dealing with cache and file IO and dynamic page generation. I plan on
looking to do something similar in the mail server my friend and I are
getting ready to write.
I'm curious how this type of ProtocolHandler would be constructed in
Mina and Berin's SEDA implementation (I can't wait to see more code
there). Would you need to build a sort of sub-pipeline within the
protocol handler to accomplish this? I think it is very important that
it is easy for someone to be able to plug in a new ProtocolHandler and
be able to take advantage of the concurrency and scalability that the
non-blocking IO and SEDA provide, but it should also be fairly
straightforward to build new pipelines.
Everything I've seen so far looks great. I'm eager to try this stuff
out in my own project.
Rich
Berin Loritsch wrote:
> Trustin Lee wrote:
>
>> Hi. I'm glad to see some comments finally. :)
>>
>>
>>
>>> The process of setting up the system is not too different from my
>>> thoughts on it.
>>>
>>
>>
>> Good.
>>
>>
>>
>>> I'm sure the internals are going to be very different from our two
>>> thought processes.
>>>
>>
>>
>> Could you explain your thought process? I think we need to cooperate.
>>
>>
> 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.
>
>>> You had a head start on mina, so you got it done sooner :). Anyway, I
>>> haven't
>>> really looked into the internals yet. Does it use the ProtocolHandler
>>> interface that
>>> the old SEDA system did? That is one of the goals I have.
>>>
>>
>>
>> No, but we can migrate very easily. I'm not using snickers yet, but
>> I'll provide a wrapper for it.
>>
>>
>
> As will I. My approach will be to add stages for each part of the
> ProtocolHandler
> object (encoder, decoder, etc.). Howeer, everything else will be fairly
> familiar and
> standard. I am using a very stable and well tested event routing
> library so as not
> to have to reinvent the wheel on that.
>
>>> I'd like to see the difference in how these perform as well as how easy
>>> it is to work
>>> with. If it looks like mina is easier to work with and seda is more
>>> scalable, we might
>>> look at merging some concepts.
>>>
>>
>>
>> I expect MINA to perform better than SEDA for a few reasons:
>>
>> 1. MINA doesn't create events and bytebuffer instances frequently.
>> 2. MINA has constant route calculation time. (SEDA takes O(n) time)
>>
>> But MINA can be slow too because she provides more complex event
>> hooks, and she has only one I/O thread. (SEDA has one for read and the
>> other for write.)
>>
>>
> My expectation is that we will have the assembly line syndrome. IOW,
> for small
> production runs it doesn't really make sense, but when you really need
> to crank
> it does better.
>
> 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.
>
>> Her strength is in its freedom; you can use only core packages or can
>> use higher-level protocol package. You can run your network
>> application in a single thread or in a thread pool. Basically MINA
>> doesn't care if the user logic runs together with internal I/O thread.
>> It is absolutely 100% up to the API user. This flexibility is
>> accomplished by decorator pattern. Currently MINA lacks rich set of
>> decorators, but I'll add them sooner or later. Here is a possible
>> example:
>>
>> Acceptor acceptor = new TcpAcceptor();
>> acceptor.bind(new InetSocketAddress(8080),
>> ThreadPooledSessionHandler.decorate(CoreAdapter.adapt(new
>> MyProtocolProvider()), /* TP size */ 16));
>>
>>
>
> 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("127.0.0.1", 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.
>
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Berin Loritsch wrote:
> Alex Karasulu wrote:
>
>> Berin Loritsch wrote:
>>
>>>
>>> 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:
>>>
>> This is similar to the SEDA of today.
>>
> With the obvious exception of the working Firewall :) I just finished
> the Firewall,
> and I am on to fleshing out the Reader/Writer stuff, and the
> ProtocolHandler
> integration will be next.
>
> Then of course is wiring stuff together and picking what ThreadPolicy
> works best.
> Of course that may differe depending on the load. Its starting to
> take shape.
>
Excellent! The ThreadPolicy stuff is really interesting.
Alex
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Berin Loritsch <bl...@d-haven.org>.
Richard Wallace wrote:
> What application are those .iml and .ipr files created in?
>
IntelliJ IDEA
--
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Richard Wallace wrote:
> What application are those .iml and .ipr files created in?
Actually Berin should not have checked these IntelliJ IDEA project and
module files since they can be generated using maven idea plugin.
Alex
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Richard Wallace <rw...@thewallacepack.net>.
What application are those .iml and .ipr files created in?
Alex Karasulu wrote:
> Richard Wallace wrote:
>
>> Berin,
>>
>> Have you put the code up anywhere? I'd like to take a look at what
>> you've got even if it's not "ready" yet.
>
>
> Berin has the code in a branch here:
>
> http://rorquids.notlong.com/
>
> Cheers,
> Alex
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Richard Wallace wrote:
> Berin,
>
> Have you put the code up anywhere? I'd like to take a look at what
> you've got even if it's not "ready" yet.
Berin has the code in a branch here:
http://rorquids.notlong.com/
Cheers,
Alex
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Berin Loritsch <bl...@d-haven.org>.
Richard Wallace wrote:
> Berin,
>
> Have you put the code up anywhere? I'd like to take a look at what
> you've got even if it's not "ready" yet.
Its in the branches section of the SEDA project in the directory repository.
--
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Richard Wallace <rw...@thewallacepack.net>.
Never mind, I see it's in the svn repository now.
Richard Wallace wrote:
> Berin,
>
> Have you put the code up anywhere? I'd like to take a look at what
> you've got even if it's not "ready" yet.
>
> Rich
>
> Berin Loritsch wrote:
>
>> Alex Karasulu wrote:
>>
>>> Berin Loritsch wrote:
>>>
>>>>
>>>> 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:
>>>>
>>> This is similar to the SEDA of today.
>>>
>> With the obvious exception of the working Firewall :) I just finished
>> the Firewall,
>> and I am on to fleshing out the Reader/Writer stuff, and the
>> ProtocolHandler
>> integration will be next.
>>
>> Then of course is wiring stuff together and picking what ThreadPolicy
>> works best.
>> Of course that may differe depending on the load. Its starting to
>> take shape.
>>
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Richard Wallace <rw...@thewallacepack.net>.
Berin,
Have you put the code up anywhere? I'd like to take a look at what
you've got even if it's not "ready" yet.
Rich
Berin Loritsch wrote:
> Alex Karasulu wrote:
>
>> Berin Loritsch wrote:
>>
>>>
>>> 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:
>>>
>> This is similar to the SEDA of today.
>>
> With the obvious exception of the working Firewall :) I just finished
> the Firewall,
> and I am on to fleshing out the Reader/Writer stuff, and the
> ProtocolHandler
> integration will be next.
>
> Then of course is wiring stuff together and picking what ThreadPolicy
> works best.
> Of course that may differe depending on the load. Its starting to take
> shape.
>
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Berin Loritsch <bl...@d-haven.org>.
Alex Karasulu wrote:
> Berin Loritsch wrote:
>
>>
>> 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:
>>
> This is similar to the SEDA of today.
>
With the obvious exception of the working Firewall :) I just finished
the Firewall,
and I am on to fleshing out the Reader/Writer stuff, and the ProtocolHandler
integration will be next.
Then of course is wiring stuff together and picking what ThreadPolicy
works best.
Of course that may differe depending on the load. Its starting to take
shape.
--
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Berin Loritsch wrote:
>
> 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:
>
This is similar to the SEDA of today.
Alex
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Berin Loritsch <bl...@d-haven.org>.
Trustin Lee wrote:
>Hi. I'm glad to see some comments finally. :)
>
>
>
>>The process of setting up the system is not too different from my
>>thoughts on it.
>>
>>
>
>Good.
>
>
>
>>I'm sure the internals are going to be very different from our two
>>thought processes.
>>
>>
>
>Could you explain your thought process? I think we need to cooperate.
>
>
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.
>>You had a head start on mina, so you got it done sooner :). Anyway, I
>>haven't
>>really looked into the internals yet. Does it use the ProtocolHandler
>>interface that
>>the old SEDA system did? That is one of the goals I have.
>>
>>
>
>No, but we can migrate very easily. I'm not using snickers yet, but
>I'll provide a wrapper for it.
>
>
As will I. My approach will be to add stages for each part of the
ProtocolHandler
object (encoder, decoder, etc.). Howeer, everything else will be fairly
familiar and
standard. I am using a very stable and well tested event routing
library so as not
to have to reinvent the wheel on that.
>>I'd like to see the difference in how these perform as well as how easy
>>it is to work
>>with. If it looks like mina is easier to work with and seda is more
>>scalable, we might
>>look at merging some concepts.
>>
>>
>
>I expect MINA to perform better than SEDA for a few reasons:
>
>1. MINA doesn't create events and bytebuffer instances frequently.
>2. MINA has constant route calculation time. (SEDA takes O(n) time)
>
>But MINA can be slow too because she provides more complex event
>hooks, and she has only one I/O thread. (SEDA has one for read and the
>other for write.)
>
>
My expectation is that we will have the assembly line syndrome. IOW,
for small
production runs it doesn't really make sense, but when you really need
to crank
it does better.
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.
>Her strength is in its freedom; you can use only core packages or can
>use higher-level protocol package. You can run your network
>application in a single thread or in a thread pool. Basically MINA
>doesn't care if the user logic runs together with internal I/O thread.
> It is absolutely 100% up to the API user. This flexibility is
>accomplished by decorator pattern. Currently MINA lacks rich set of
>decorators, but I'll add them sooner or later. Here is a possible
>example:
>
>Acceptor acceptor = new TcpAcceptor();
>acceptor.bind(new InetSocketAddress(8080),
>ThreadPooledSessionHandler.decorate(CoreAdapter.adapt(new
>MyProtocolProvider()), /* TP size */ 16));
>
>
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("127.0.0.1", 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.
--
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Trustin Lee <tr...@gmail.com>.
Hi. I'm glad to see some comments finally. :)
> The process of setting up the system is not too different from my
> thoughts on it.
Good.
> I'm sure the internals are going to be very different from our two
> thought processes.
Could you explain your thought process? I think we need to cooperate.
> You had a head start on mina, so you got it done sooner :). Anyway, I
> haven't
> really looked into the internals yet. Does it use the ProtocolHandler
> interface that
> the old SEDA system did? That is one of the goals I have.
No, but we can migrate very easily. I'm not using snickers yet, but
I'll provide a wrapper for it.
> I'd like to see the difference in how these perform as well as how easy
> it is to work
> with. If it looks like mina is easier to work with and seda is more
> scalable, we might
> look at merging some concepts.
I expect MINA to perform better than SEDA for a few reasons:
1. MINA doesn't create events and bytebuffer instances frequently.
2. MINA has constant route calculation time. (SEDA takes O(n) time)
But MINA can be slow too because she provides more complex event
hooks, and she has only one I/O thread. (SEDA has one for read and the
other for write.)
Her strength is in its freedom; you can use only core packages or can
use higher-level protocol package. You can run your network
application in a single thread or in a thread pool. Basically MINA
doesn't care if the user logic runs together with internal I/O thread.
It is absolutely 100% up to the API user. This flexibility is
accomplished by decorator pattern. Currently MINA lacks rich set of
decorators, but I'll add them sooner or later. Here is a possible
example:
Acceptor acceptor = new TcpAcceptor();
acceptor.bind(new InetSocketAddress(8080),
ThreadPooledSessionHandler.decorate(CoreAdapter.adapt(new
MyProtocolProvider()), /* TP size */ 16));
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Berin Loritsch wrote:
> Trustin Lee wrote:
>
>> Hi,
>>
>> I implemented protocol layer and here is a new example which uses it:
>>
>> http://svn.apache.org/viewcvs.cgi/incubator/directory/seda/branches/trustin/src/examples/org/apache/mina/examples/reverser/
>>
>>
>> It is a server which reverses all text lines client sends and reply
>> back.
>>
>> I want to know how you guys feel this API, so please leave some
>> comments here! :)
>>
>> BTW I decided to name this new API as 'MINA'. MINA means 'A
>> Multipurpose Infrastructure for Network Applications', 'South' in
>> Japanese, or just a girl's name. HDYT?
>>
>>
>>
> Does it use the ProtocolHandler interface that
> the old SEDA system did? That is one of the goals I have.
>
Yep this was a big concern for me that I've reiterated to Trustin.
However wrappers are not out of the question if I don't have to write
them ;).
> I'd like to see the difference in how these perform as well as how
> easy it is to work
> with. If it looks like mina is easier to work with and seda is more
> scalable, we might
> look at merging some concepts.
>
Yep my thoughts exactly. MINA will respond fast when the number of
users is small. SEDA on the other hand will scale better with load.
MINA reponsiveness will outperform SEDA bellow some threshold. But SEDA
will scale better. In the end servers with long living TCP connections
may benefit more from SEDA than MINA.
I think the best approach is to play with all of them :). I'm not
adverse to having two or more different networking layers to work with.
Even two layers in the same framework for that matter that compliment
one another.
This does however place more importance on the ProtocolProvider
interfaces. If there are adapters then this should be managed behind
the scense by the networking layer. This way we can snap in the LDAP,
Kerberos and other protocol providers into the two framework
implementations without alteration. This interop should be provided so
we can really test these frameworks side by side even in the same server
instance using different ports for the same protocol served by two
different networking layers. Sick as it sounds it will help us get
some statistics.
Alex
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Berin Loritsch <bl...@d-haven.org>.
Trustin Lee wrote:
>Hi,
>
>I implemented protocol layer and here is a new example which uses it:
>
>http://svn.apache.org/viewcvs.cgi/incubator/directory/seda/branches/trustin/src/examples/org/apache/mina/examples/reverser/
>
>It is a server which reverses all text lines client sends and reply back.
>
>I want to know how you guys feel this API, so please leave some
>comments here! :)
>
>BTW I decided to name this new API as 'MINA'. MINA means 'A
>Multipurpose Infrastructure for Network Applications', 'South' in
>Japanese, or just a girl's name. HDYT?
>
>
>
The process of setting up the system is not too different from my
thoughts on it.
I'm sure the internals are going to be very different from our two
thought processes.
You had a head start on mina, so you got it done sooner :). Anyway, I
haven't
really looked into the internals yet. Does it use the ProtocolHandler
interface that
the old SEDA system did? That is one of the goals I have.
I'd like to see the difference in how these perform as well as how easy
it is to work
with. If it looks like mina is easier to work with and seda is more
scalable, we might
look at merging some concepts.
--
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Trustin Lee wrote:
>Hi,
>
>I implemented protocol layer and here is a new example which uses it:
>
>http://svn.apache.org/viewcvs.cgi/incubator/directory/seda/branches/trustin/src/examples/org/apache/mina/examples/reverser/
>
>It is a server which reverses all text lines client sends and reply back.
>
>I want to know how you guys feel this API, so please leave some
>comments here! :)
>
>
>
Looks like clean stuff that would be very zippy. It's definately not
the SEDA model. Also as we spoke about it we need to work on issues
relating to ease of understanding and use. But its clean stuff I like it.
>BTW I decided to name this new API as 'MINA'. MINA means 'A
>Multipurpose Infrastructure for Network Applications', 'South' in
>Japanese, or just a girl's name. HDYT?
>
>
That fine with me sure.
Alex
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Trustin Lee <tr...@gmail.com>.
Hi,
I implemented protocol layer and here is a new example which uses it:
http://svn.apache.org/viewcvs.cgi/incubator/directory/seda/branches/trustin/src/examples/org/apache/mina/examples/reverser/
It is a server which reverses all text lines client sends and reply back.
I want to know how you guys feel this API, so please leave some
comments here! :)
BTW I decided to name this new API as 'MINA'. MINA means 'A
Multipurpose Infrastructure for Network Applications', 'South' in
Japanese, or just a girl's name. HDYT?
Cheers,
Trustin Lee
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [seda] A preview on redesigned SEDA (or Netty?)
Posted by Trustin Lee <tr...@gmail.com>.
The API has been changed slightly, but I believe you can understand them easily.
The URL of echo server example has been changed:
http://svn.apache.org/viewcvs.cgi/incubator/directory/seda/branches/trustin/src/examples/org/apache/netty/examples/echoserver/
and NetCat example is added. (network 'cat' command)
http://svn.apache.org/viewcvs.cgi/incubator/directory/seda/branches/trustin/src/examples/org/apache/netty/examples/netcat/
Any questions and critiques are welcome! Actually I really need it to
create simple yet useful API.
BTW Alex suggested me to name this new API other than SEDA or Netty.
If you have any idea on its new name, just let me know. :)
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/