On Fri, 14 Dec 2001 08:38, Berin Loritsch wrote:
> In SEDA, there is a difference between the input side of a Queue, and the
> input side of the Queue.
you of course mean input and output ;)
> 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?
In my event based architecture I do (and think it is a good idea). This is
also the terminology I wished I had used in LogKit all those years ago. Still
haven't looked at SEDA source to see if it right terminology.
If you go back to our discussions about a pipeline we talked about sinks
being the end of a pipe and sources being started of pipe - which is slightly
different from this way (were each stage in pipe has end and a start).
> 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.
It should be hidden away behind the interface. The source just generates
events and the sink consumes them. If we are having a SEDA style architecture
then that would mean enqueue/dequeuing events into relevent queues but if it
was a simpler architecture it could mean just executing next stage.
> 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.
I disagree. For example if you have a number of requests (lets say UDP
requests). Several are of different types and thus different priorities. Only
the application specific portion can determine which packets are safe to drop
and so on. This could be layered so that there is another layer between stage
and queue that does this for you according to desired performance
characteristics but that could mean that the stage is doing extra work when
we really want to reject the messages as early as possible.
Goto the SEDA homepage and they have some papers on that IIRC. Something like
"why virtualization is bad" or similar.
> There are also methods for transactional queuing. It is unclear
> whether this is appropriate or not. As an example:
>
> Object key = null;
>
> try
> {
> 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
> approach.
Thats useful when you want to know if it is possible to queue stuff before
you do the work. I do a similar thing in my architecture (though less
sophisticated than SEDA). So first you want to know if you can queue X
elements. If so you do the work required to actually put them into state
ready for next stage. If not then you zap the queue elements.
--
Cheers,
Pete
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
