I'd like to have a discussion later about what this engine thing is and how the mediator gets hold of it. But before that happens could someone provide a simple use case where we're going to need this facility?
...ant
On 10/21/05, Paul Fremantle <[EMAIL PROTECTED]> wrote:
I've changed my mind :-)
So the benefit of the return int is that you can keep the same thread and save some cycles.
But I think its possible to keep the same thread anyway if we are clever:
Suppose the mediator does:
{
engine.insertmessage(msg);
return false;
}
The engine can hang onto the reference for the new message, and not spawn a new thread until the return of the current mediator. In the case where it returns false it can reuse the thread. Its really a matter of optimising the thread pool. So I would be happy with a simple boolean return.
PaulOn 10/21/05, Saminda Abeyruwan < [EMAIL PROTECTED]> wrote:Hi,
So we are looking at Mediator interface like,
public int mediate(MessgeContext msgCtx) ;
+1 for "int" approach. So, this way, if we can achieve extensibility in future.
SamindaOn 10/21/05, Deepal Jayasinghe < [EMAIL PROTECTED]> wrote:Hi paul;+1 for that approach, return an int instead a boolean
Thanks,
Deepal
................................................................
~Future is Open~----- Original Message -----From: Paul FremantleSent: Thursday, October 20, 2005 7:50 PMSubject: Re: Rule Engine / DispatcherAnt,
I was thinking that it would be up to the Engine whether to spawn a new thread or not. But I guess the point is if its a call rather than a return, that would be complex. On the other hand, I guess we could simply change the response from a boolean to an int
e.g.
public static final int CONTINUE=0, END=1, RESTART=2; etc
That way the engine can decide whether to use a new thread or continue on the existing one. However, we shouldn't make assumptions about which thread a mediation is run on.
Paul
