directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Re: some comments and questions
Date Mon, 13 Sep 2004 13:54:30 GMT
Cetin Karakus wrote:

> Hi Alex,
> I have been reading through SEDA codebase recently and I would like
> to ask some points.
> 
> 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?

Not having looked into the code yet, how exactly is the observer pattern
mixed with the SEDA one?

> 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

Well, if the callback is a null handler (i.e., an empty method) the
callback will be optimized out by the JVM's Hotspot recompiler.  What
is a concern though is how many listeners are there?  If the set of
listeners being called are small (1-3) then the impact is livable, esp.
if the benefits of the observer pattern outway other drawbacks.  If the
number of listeners is high, or the work the listeners do is expensive,
then they need to be notified outside of the critical path.  IOW, a
thread specifically dedicated to the observer pattern notification.

This addresses the critical path performance concerns, but it does
also add additional complexity and less predictability of exactly when
those events will fire (it could be as much as a second or two after
the cause for the event when under heavy load).

> 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.
> 
> 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

The idea of a predicate is a simple allow/disallow decision.  That is
the contract.  It is very useful and quick.  The idea you are proposing
can be done with a "LogicEnabledPredicate", but it will always be slower
than just coding what your really want.  Not to mention the apparent
predictability of whether or not an event will be allowed is easier to
understand many times if it is programmed in straight-way.

-- 

"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

Mime
View raw message