avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: Silk == More Seda Extractions
Date Mon, 04 Feb 2002 14:41:29 GMT


> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> > If this is the difference between having a single handleEvent() method
> > and having a more do-this-stuff method name such as fetchMailForUser()
> > I see three cases:
> >
> > 1) Synchronous calls through discrete interface. The method
> creates an event
> > and enqueues it, then blocks until completion event is recieved
> or timeout.
>
>
> That is the part that I don't like.   Synchronous calls that take
> a long time
> are bad for scalability.  However, most of our blocks are fairly quick to
> process events.

True, and this will be a major problem if a stage requires a block. That is,
if MyStage calls MyBlock and the call is synchronous. But I would claim
that that is bad architecture and that if such a bottleneck appears,
the block should be rewritten as a SilkServer with stages.

> > 3) Async call through Stage interface. The event is taken straight into
> > the Silk server.
> >
> > Case 3 is for when you connect a Silk HTTP block with a Silk FileCache
> > block.
>
>
> That would be a common use.
>
>
>
> > So, if we just see the block as a Stage (which it is), there shouldn't
> > be any problems.
> >
> > /LS
>
>
> Cool, but what about case #2, how would you approach that?

Berin,

as I see it, the problem is really in the return value. Suppose
a block exposes this interface:

public interface MyBlock {
  public void doStuff () throws SinkFullException;
}

Given that this is the interface for a set of stages served by a
SilkServer, the doStuff method would look like this:

public void doStuff () throws SinkFullException {
    SilkServer server = <obtain SILK server>;
    Stage stage = server.lookup ("Name of the initial stage - this is where
processing starts.");
    stage.enqueue (new DoStuffRequest ());
}

The DoStuffRequest goes through the appropriate stages and eventually
completes. Since the method doesn't return anything, we're done.

It gets trickier if the method must return the result of the processing,
perhaps a success/failure code. Since we must not block, the return value
must be signalled back via an event handler. I would go for this approach:

public interface MyBlockResultHandler {
  public void handleResult (String result);
}

public interface MyBlock {
  public void doStuff (MyBlockResultHandler handler) throws
SinkFullException;
}

public void doStuff (MyBlockResultHandler handler) throws SinkFullException
{
    SilkServer server = <obtain SILK server>;
    Stage stage = server.lookup ("Name of the initial stage - this is where
processing starts.");
    stage.enqueue (new DoStuffRequest (handler));
}

Once the DoStuffRequest has been processed through all stages, the final
stage calls
the handler.handleResult method to notify the original caller of the result
of the processing.

For example, the ResultHandler could be used in a print spooler system
to continuously provide updates of the progress the document is making.

/LS


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


Mime
View raw message