directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: some comments and questions
Date Mon, 13 Sep 2004 16:46:58 GMT
On Mon, 2004-09-13 at 07:15, Cetin Karakus wrote:
> Hi Alex,
> I have been reading through SEDA codebase recently and I would like
> to ask some points.
> 1- 
> I have noticed that there are some implementation classes whose names
> usually follow Default* pattern in  api/ source tree. Why this is so?
> Is it because they are trivial implementations?

Well no they are not trivial implementations.  These implementations
will usually get wrapped to fit into another framework.  Take for
example Avalon a wrapper may be built for each component so that it
plugs into Merlin and uses all the lifecycles to setup each component.

This way the default implementation used is the core POJO while the
Merlin wrapper adapts it to the framework.  I know 'Default' does not
sound all that great though.  Do you have any recommendations?

> 2-
> There is a heavy usage of observer pattern. I know that SEDA is a event based 
> architecture and it is claimed to enable massive scalability in client/server
> applications by its author. My question is that while scalability is
> absolutely a
> strong motive in the design, do we should disregard performance
> concerns althogether?

No you're right.  Performance should be considered definately.  However
let's get the design correct then we can start tuning this thing.  I'm
in the process of getting a free license to JProbe contributed to us by
Quest so we can analyze the code and make it more efficient. 

> I may be wrong but arent the callback interfaces exposed through
> *Monitor objects
> are too much fine-granular? My concern is that they may result in
> excessive callbacks
> throughout event processing pipeline that may cause serious
> performance degradation

These callbacks have nothing to do with the event processing pipeline
but are a means to abstract away the need to log.  Take a look here at
this paper for more info:

Basically the monitor is an interface exposed by the service to tell
those outside of it what situations are notable.  Rather than just log
these situations (non-pipeline events) the service implementations
notify a monitor via callbacks.  So if we just used logging instead of a
monitor we would still be making calls to log.debug() or whatever right
for these notable situations.   Instead we have generalize notification
so it can be used for more than just logging.

Looks like Berin also responded on this showing how the JVM removes do
nothing calls so we're safe and do not pay the price for the new call
stack.  This is something the commons folks should also hear because
they think this is terribly inefficient.

> 3-
> >From my current understanding, "Stage"s are the abstraction made to
> allow processing
> of the events enqueued to the same place by a common event handler.
> As events are enqueued, they are made available to be processed. The
> predicate objects
> that examine a given event and decide to (dis)allow an event to be enqueued to 
> a given stage is the dynamic, configurable mechanism through which
> stages can be
> programmed to process only certain types of events.

Yes this is true.

> As such, shouldnt stages allow more flexible combination of predicates that 
> allow makeup of complex boolean expressions consisting of multiple
> levents of boolean operations like:
> ( (predicate1 and predicate2) or (predicate3 and predicate4)) and  predicate4

See the other email response to this specificall where you actually show
how we can achieve this.  I think your right about how to do it just
wondering if we should bother.


View raw message