A few comments in line surrounded by <ant></ant> to try to keep it clearerOn 10/20/05, Vikas < [EMAIL PROTECTED] > wrote:Hi all,
I do think that "Synapse should control this instead of the mediation."
But a few afterthoughts:
---wouldn't re-evaluating all rules at this point be same as thinking that a new message is being processed?
<ant>Good point. I guess the one difference when using the non-blocking API Paul is talking about is that a new thread is used to re-evaluate the rules - although I'm not sure how useful that is if the original thread just terminates without doing anything more.
I agree. If more rules are available to the "arrived" message, keep-on looping on the same tread with a state be more efficient.
Maybe there needs to be a way to say reintroduce the messaging using the current thread. Would be easier to implement that if Synapse was controlling the reintroduction instead of the mediator.
Now , re-introducing of the new MessageContext to current thread is done at the MessageReceiver level, if more rules exists. This has to be done, inorder to cope with the Axis2 symantics. Mediator *should not introduce* the new MC and if do it is very cumbersum to implement.
It does seem like having a way for a mediator to introduce new messages into Synapse locally to be processed concurrently would be a useful feature, what ever the outcome of this discussion.</ant>
This can be done trough Dependecy Injection in MR. But i personally don't like that idea, though, {Mediator introducing the new MC}
For the new message injected into the system by synapse[on behalf of a mediation] or the mediation itself
---- There r two cases
*There might be a set of mediation rules for the other service which definitely needs to be done before accessing the other service (else it's a breach of contract)
*Bypass the global rules for such messages[in case the global rule says..maintain count of incoming requests]
<ant>Couldn't the rule control this? So the counting rule in your example would only match messages coming from an HTTP transport listener, or perhaps any non-local transport listener?</ant>
Yes. This is the soul purpose of having a genuine ruling mechanism.
--- So a 'true' from the mediation(a state in the state-machine sense) would tell the engine to go forward in the particular branch of the state-machine and a 'false' would lead to the state-machine's initial state(i.e. revaluation of rules).[As if a new message has come in.]
<ant>There still needs to be a way for a mediator to say to Synapse "stop, do nothing more with this message", which is what I thought returning false was going to mean.
It was the same picture i have in my mind, though.
I still like the idea that the Synapse rule processor is able to spot that a mediator has done something that means re-evaluation is necessary. Even if that's quite simplistic for now, such as when a mediator changes anything in the headers.</ant>
--- Can somebody shed some light on how complex would it be for the engine to keep track of the rule that caused the mediation to be called (thus identify the property, or the 'special thing' thats important). Complexity in terms of both data and computation.
--- Also it will have to then keep track of all the decision points that had been passes in the state machine..[ It would implementation specific – but it definitely needs to hold this information]
Have a good day!
----- Original Message -----
From: ant elderSent: Wednesday, October 19, 2005 5:12 PMSubject: Re: Rule Engine / DispatcherOk I agree with you, it seems better not to re-evaluate all the matching rules. I guess the point I was debating is wouldn't it be nicer if Synapse controlled this instead of the mediator?
The Mediator is just like any regular mediator without using any special Synapse nonblocking API:
public boolean mediate(Message m) {
m.setTo("http://xmethods/stockquote");
return true;
}
And Synapse says, oh, you've changed wsa:to, thats one of those "special things", better make this a new request.
That way we can change our minds about what constitutes a "special thing" without having to change any mediator code, and we could maybe build some smarts into Synapse so that it can somehow check if any rules before the current rule were interested in a wsa:to of http://xmethods/stockquote and if not then this wouldn't have to be a new request.
...ant
On 10/19/05, Paul Fremantle <[EMAIL PROTECTED]> wrote:Ok. So is exactly the case where you want to say this is a new message. I agree with that scenario. But I still think that it helps limit the possibility of endless loops and improves the performance if the default behaviour is not to re-evaluate the matching rules between rules.
Pau
