some comments and questions

[Cetin Karakus <ce...@gmail.com>]

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?

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

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

Re: some comments and questions

[Berin Loritsch <bl...@d-haven.org>]

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

Re: some comments and questions

[Alex Karasulu <ao...@bellsouth.net>]

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:

http://wiki.apache.org/avalon/AvalonNoLogging

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.

Alex