Re: [Axis2][Revisit]How about making Message context executable?

[Aleksander Slominski]

Venkat Reddy 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.
 

i thin that implies need for HandlerChain and ability to "manually" pass 
context between handlers in the chain - calling each handler process(MC) 
and depending on result call next handler or not ...


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. In that sense, Phase and EecutionChain might qualify to have
pause 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.
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.
 

would it be the simple solution possible?
thanks,
alek

- 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 like to
add 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 like
and set the PAUSE flag to true.
*  Other handlers upon receiving this PAUSE MC, they won't do anything. (Or
Engine can have a mechanism to stop proceeding the message to rest of the
handlers)
* 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 position
of the execution chain, and ask handlers to proceed.
* When handler or anyone decides, that the PAUSEd MC should start, it will
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: axis-dev@ws.apache.org
Subject: Re: [Axis2][Revisit]How about making Message context executable?
Hi 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 is
used to pass state between pipelined handlers
Engine exists independent from services and messages and its purpose it
to help during message processing
if AxisEngine is removed what will replace it to keep state independent
of 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 get
a 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: axis-dev@ws.apache.org, Srinath Perera <[EMAIL PROTECTED]>
Hi there Srinath and all,
This is probably a complete 180 degree turn from where we were heading
(well not exactly a backward leap, but a drastic change in direction).
The 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 such
a change. It will be impossible on later stage.
On Thu, 3 Mar 2005 17:54:59 +0600, Srinath Perera <[EMAIL PROTECTED]>
         

wrote:
       

Hi All;
This is regarding the invoke, pausing and resuming the the invocation!
To this point this is implemented with an ExecutionChain kept in the
MessageContext ..calling the invoke on the MessageContext.
But more I look at the code more I convinced the way the Glen has done
it in EngineToy by putting the invoke(), resume() and pause() in the
MessageContext would yield simpler and better code. Only catch is that
it will make the MessageContext executable .. making it bit away from
what 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 and
put the send and receive in to the MessageContext. Making it our
approach is to create the information bag, messageContext and ask it
to send(), recive(), pause() .. I just want to know what people think
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