Re: Dynamic stage creation

Also, a coder could want to use direct method call because he want that
a desired action be executed as fast as possible; so he don't want that
its urgent event waits its turn in the queue.

So, I suggest another solution, more elegant, that can efficiently
replace standard method calls:

interface SinkIF {

   Future enqueueFirst(QueueElementIF x) throw SinkException;

   /** return null if the element was not enqueued */
   Future enqueueLossyFirst(QueueElementIF x);

   Future blockingEnqueueFirst(QueueElementIF x);

}

The key idea is that the given enqueued element will preempt all other
elements in the queue.  So, this element will be processed as fast as
possible.

The other key idea is that we return a Future object that wrap the
return value (if any). Note that the method Future.get() waits for the
retrieval of the result, so, again, it have almost the same behaviour
than a standard synchronous method call.

The drawback of enqueueFirst is that it requires to acquire all queue
locks.  So, it's a costly operation that can decrease concurrency.  But
this is not really a problem since this method should be used rarely.

Also I like this idea more than StageIF.invoke because the threads in
one stage cannot cross stage boundary.


Please, I would be interested by your comments.


Jean Morissette wrote:
 > Nobody has said their opinion about that. :-(  But, it's really an
 > important change.  This imply that the coder will not be able any more
 > to call directly handler methods!  It's because the handler
 > creation/destruction would be totally controlled by SS.  So, the coder
 > cannot have a reference on it (or, at least, on the real handler).
 >
 > Do you think that removing direct method call capability is a major
 > constraint?  If yes, I'm wondering how to overcome that?
 >
 > One main characteristic of direct method calls is that they can return
 > value.  To provide the same functionality, we could create this method:
 >
 > Future enqueueCallback(QueueElement qe);
 >
 > The difference over direct method calls is that this method is
 > asynchronous.  If we want something synchronous, we could create this
 > method:
 >
 > StageIF.invoke(String methodname, Object[] args);
 >
 > and use reflection to call public methods from the real handler.
 >
 > This last solution could be implemented synchronously or asynchronously.
 >
 > What do you think?
 >
 >
 >
 > Quartz wrote:
 >
 >>> Like I have said, a handler that is preconfigured outside of the
 >>> init() can be dangerous if it is reprogrammed.
 >>>
 >>> Also, I think that its better to have an uniform and controlled
 >>> process for creating handlers.  This offers many interesting
 >>> possibilities.  By exemple, if Sandstorm is totally responsible of
 >>> creating handlers, we could instrument a handler, or wrap it behind a
 >>> proxy.  This will be important if we support load distribution (that
 >>> is, stage migration to other computers).
 >>>
 >>> Do you agree about my suggestion?
 >>
 >>
 >>
 >> I don't have comments. Ask users that expect to pass a
 >> pre-instanciated handler.





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click