avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Event Queues
Date Thu, 13 Dec 2001 21:38:13 GMT
In SEDA, there is a difference between the input side of a Queue, and the
input side of the Queue.  They are called Source and Sink respectively.
There is futher a Queue interface that extends both.

In essence, what happens is that each Stage is connected by a full queue.

For instance, let us assume we have a Stage that puts events into a Sink.
That Sink is only part of the event queue, the other side of which is a
Source for another stage.

The question I have is one of preference.  Is it worth it to separate the
input and output sides of the Queue?

I think it does simplify the the implementation of stages, as the
developer typically won't cast the Sink as a Queue to get at the other
side of the Queue.  I also think that it is not preferable to mix these

If this is the case, what are the preferred names for the Source and Sink
equivalent?  It is a Source's responsibility to dequeue events, and the
Sink's responsibility to enqueue events.

The interfaces as part of SEDA mix concerns, so I intend to place a
simpler interface in Avalon.  For instance, it is not the queue user's
responsibility to determine if the event should be placed in a lossy manner
or not.  There are also methods for transactional queuing.  It is unclear
whether this is appropriate or not.  As an example:

Object key = null;

     key = queue.enqueuePrepare( QueueElement[] elements );
     queue.enqueueCommit( key );
catch ( SinkException se )
     queue.enqueueAbort( key );

I think I may make that a specialization, and simply focus on the simplest


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message