Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 31705 invoked from network); 10 Mar 2005 08:44:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 10 Mar 2005 08:44:08 -0000 Received: (qmail 76524 invoked by uid 500); 10 Mar 2005 08:44:04 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 76504 invoked by uid 500); 10 Mar 2005 08:44:03 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 76491 invoked by uid 99); 10 Mar 2005 08:44:03 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from mail.opensource.lk (HELO squid.cmb.ac.lk) (202.51.147.3) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 10 Mar 2005 00:44:02 -0800 Received: from ExtremeM ([220.247.230.8]) by squid.cmb.ac.lk (8.12.9/8.12.9) with ESMTP id j2A8lugQ073165; Thu, 10 Mar 2005 14:48:21 +0600 (LKT) (envelope-from chinthaka@opensource.lk) Message-Id: <200503100848.j2A8lugQ073165@squid.cmb.ac.lk> Reply-To: From: "Eran Chinthaka" To: , "'Venkat Reddy'" Subject: RE: [Axis2][Revisit]How about making Message context executable? Date: Thu, 10 Mar 2005 14:42:00 +0600 Organization: Lanka Software Foundation MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUlSuzD0M0jHe7JRy+yDBVHtd//rwAAHFQg In-Reply-To: X-Virus-Scanned: by amavisd-new X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N > > 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. 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. > > 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 > 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 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 > 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" > > > >To: > > > >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 > > > >>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 > > > >> > > > >> > > > >>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 > > > > >> > > > >> > > > >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 > > > > > > > > > >