axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject [AXIS2] WSRM and MC pause/resume [Re: [Axis2][Revisit]How about making Message context executable?
Date Thu, 10 Mar 2005 18:01:51 GMT
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 it
>sees that it has recd the 3rd message and it retrieves it. Then the RM
>handler, calls engine.receive with the retrieved mc.
>  
>
when 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)

>>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)?

>>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.
>>    
>>
>
>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.
>  
>
i would be interested to see if handler chain can be modeled as 
handlerChain and i can do somehitng like
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
>><chinthaka@opensource.lk> 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:hemapani@gmail.com]
>>>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" <hemapani@gmail.com>
>>>>>To: <dev@geronimo.apache.org>
>>>>>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 <ajith.ranabahu@gmail.com>
>>>>>>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 <hemapani@gmail.com>
>>>>>>
>>>>>>
>>>>>>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
>>>>>>            
>>>>>>
>><hemapani@gmail.com>
>>    
>>
>>>>>>            
>>>>>>
>>>>>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


Mime
View raw message