Eran Chinthaka wrote:
IMHO, the question of whether to shift the invocation logic from axis engine to message context might also depend on support for asynch messaging.
To talk about pause and resume, though i'm not sure how pervasive is
the need for this, currently axis engine has no control over
processing once the exceutionChain.invoke() is called. The triggering
logic (calling invoke) is hierarchically dispersed among engine,
ececutionChain, and phase, while the processing logic is expected in
Handlers. I need more help to understand who calls resume operation -
is it different thread which might have knowledge about when to call
resume? The handler which called msgCtx.pause() might not be able call
resume since the engine.send() has returned.
Lets take RM for example.
You have recd the 3rd message and you have not recd the 2nd. So the RM
handler sets PAUSE the mc and save the mc in "anyway" and engine.recieve
returns.
what about when machine is restarted?
how to save mc into database not just pause it and keep its state in memory?
how to resume processing *from* message context state that is in database?
When the 2nd message comes, RM handlers passes that message forward and itwhen machine is restarted axis2 services are retsrated as well and it reads from DB all pending messages and in future injects them back into processing pipeline (when message 3 arrives)
sees that it has recd the 3rd message and it retrieves it. Then the RM
handler, calls engine.receive with the retrieved mc.
Also it is not enough to save just the reference to the paused
handler; we need to save the phase info also so that excetuionChain
can start again with the paused phase which in turn resumes the paused
handler.
I should say MC must have enough information to restart execution from the middle of the system.
In that sense, Phase and EecutionChain might qualify to have
enough to restore from DB (or other stable storage)?
i would be interested to see if handler chain can be modeled as handlerChain and i can do somehitng likepause and resume methods on them. So Handler calls Phase.pause() and
phase calls executionChain.pause(). Someone can later call
ExecutionChain.resume() resulting in Phase.resume() etc.
IMO, Phases are conceptual only. So calling phase.resume() is bit weird. And
execution chain is within the engine and let engine *only* deal with that.
handlerChain.processFromPosition(2, messageContext)
this would allow WSRM to inject back message into handlerChain to continue execution from point after WSRM hanler (asumming WSRM handler was at position 1).
just ideas,
alek
I also think that asynch messaging might eventually require queued
messageCtx objects processed by an Axis engine that operates on a
seperate thread. In this context, the MsgCtx objects are pure data
objects, and no logic.
I'm not sure about this. Please explain a bit more. And for your information, we have implemented a non-queue methodology in the client api for async message support.
-- Eran Chinthaka
- venkat
On Thu, 10 Mar 2005 14:06:57 +0600, Eran Chinthaka
<[EMAIL PROTECTED]> wrote:
Well, I didn't exactly understood the meaning of MC executable. But liketo
likeadd some thing to Srinath's proposal.
* put PAUSE flag in MC
* if a handler needs to pause the mc, mc has a field to mention last
executed handler. Then handler saves or persists the mc in anyway, it
and set the PAUSE flag to true.(Or
* Other handlers upon receiving this PAUSE MC, they won't do anything.
Engine can have a mechanism to stop proceeding the message to rest ofthe
handlers)position
* then
* send and receive methods of engine checks the MC for a last executed
handler, if available. If available he can position the MC in that
of the execution chain, and ask handlers to proceed.will
* When handler or anyone decides, that the PAUSEd MC should start, it
executable?call engine.recieve() or engine.send().
Will that solve the problem ? And will that help RM too ??
-- Eran Chinthaka
-----Original Message-----
From: Srinath Perera [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 10, 2005 9:55 AM
To: Aleksander Slominski
Cc: [email protected]
Subject: Re: [Axis2][Revisit]How about making Message context
isHi Alek;
what is the purpose of MC and what is the purpose of Engine?
Messgae context is basically the place holders for the all the information! Engine is the stateless class that holds the invocation logic!
i always though that MC exists for time that message is processed and
itused to pass state between pipelined handlers
Engine exists independent from services and messages and its purpose
independentto help during message processing
if AxisEngine is removed what will replace it to keep state
getof message processing?
Alek the Q come as follows, as the message context is the bag of information we plan to have way to pause and resume the invocation!
msgctx.pause(); msgcts.resume();
With these two methods MessageContext is already executable!. Is there are any other places we need keep the pause(), resume() methods like engine. What I thought was should we marry the logic and the info both in to message context.
I agree that would overload the message context , I purpose follwoing as the solution
1) MessageContext has a flag called paused default to false 2) if some handler set the falg true the execution will halt from that handler, and the engine.send(..) or engine.recive(..) will return 3) the Handler may store the MessageContext and reset the pause later and call engine.send() or recive() later. Then the execution starts from the place where the it is stoped
Thanks Srinath
Sanjiva Weerawarana wrote:
Um, Srinath wrong list? ;-)
Sanjiva.
----- Original Message ----- From: "Srinath Perera" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 07, 2005 3:49 PM Subject: [Axis2][Revisit]How about making Message context executable?
Hi All;
I put this Q about making the MessageContext executable? I do not
headinga clear response .. May be it does not call for enough attention?
But I feel this is bit too bigger change to do without enough community input .. So I feel we should hold it back for the F2F. But then "pause the engine execution at some state" should wait too thoughts? Srinath
---------- Forwarded message ---------- From: Ajith Ranabahu <[EMAIL PROTECTED]> Date: Fri, 4 Mar 2005 16:49:43 +0600 Subject: Re: [Axis2]How about making Message context executable? To: [email protected], Srinath Perera <[EMAIL PROTECTED]>
Hi there Srinath and all,
This is probably a complete 180 degree turn from where we were
direction).(well not exactly a backward leap, but a drastic change in
suchThe Message Context (MC) was pursued only as a property bag. Now we
are trying to put executable actions there! So the role of the MC is
changed now. I am not sure what this means to the structure of axis.
I guess this needs to be thought out carefully.
BTW if we are to do such a change this is the best time to tackle
<[EMAIL PROTECTED]>a change. It will be impossible on later stage.
On Thu, 3 Mar 2005 17:54:59 +0600, Srinath Perera
invocation!
wrote:
Hi All;
This is regarding the invoke, pausing and resuming the the
theTo this point this is implemented with an ExecutionChain kept in
doneMessageContext ..calling the invoke on the MessageContext.
But more I look at the code more I convinced the way the Glen has
theit in EngineToy by putting the invoke(), resume() and pause() in
thatMessageContext would yield simpler and better code. Only catch is
fromit will make the MessageContext executable .. making it bit away
andwhat we percive about it!
thoughts?
I have a bit more revolutionary proposal to add (hope I will not
killed for saying this :D ) that is to get rid of the AxisEngine
itput the send and receive in to the MessageContext. Making it our
approach is to create the information bag, messageContext and ask
thinkto send(), recive(), pause() .. I just want to know what people
about this?
Thanks Srinath
-- Ajith Ranabahu
-- The best way to predict the future is to invent it - Alan Kay
-- The best way to predict the future is to invent it - Alan Kay
