Peter Donald wrote:
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 ;)
Err, yes.
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).
In the big picture, it is this way with SEDA. The specifics though, led
Matt Welsh to have Source be dequeue on the Source (i.e. the ThreadManager dequeues the events and forces the Stage to Handle the
events--then the Stage enqueues the events in the *next* queue).
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.
I was thinking of different types of queues...
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.
---------------------------------------------------- Sign Up for NetZero Platinum Today Only $9.95 per month! http://my.netzero.net/s/signup?r=platinum&refcd=PT97
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
