|
⇤ ← Revision 1 as of 2004-12-16 04:49:56
Size: 32017
Comment:
|
← Revision 2 as of 2009-09-20 22:47:41 ⇥
Size: 32017
Comment: converted to 1.6 markup
|
| No differences found! | |
topics discussed: In flow of the engine. Providers functionality. Bit of out flow ACTIONS (AIs?):
[09:04] *** Weekly Axis2 chat [09:04]<gdaniels> hi all [09:05]<Ajith> hi glen [09:05]<Deepal> so shell we start :) [09:05]<Chinthaka> hi glen, we thought u might be late [09:05]<Jaliya> Hi Glen [09:05]<gdaniels> I was a little, but not much :) [09:06]<Srinath> hi glen [09:06]<Srinath> shall we start [09:06]<gdaniels> Hey Srinath, Jaliya [09:06]<gdaniels> So engine and client API [09:06]<Srinath> yes [09:06]<Jaliya> yes [09:06]<gdaniels> but I think we'll probably spend the whole time on engine... [09:07]<Srinath> :D [09:07]<Srinath> let see [09:07]<gdaniels> I'm just bringing prototype2 up in another window [09:07]<Srinath> glen where shall we start [09:08]<gdaniels> Well, let's start with handlers, phases, and how the engine knows what to execute [09:08]<gdaniels> I'm not sure we have a solid shared understanding of this yet [09:08]<Srinath> yes [09:08]<Deepal> glen what we do at the deployemnt time is we craete what is call ececutioncahin [09:09]<gdaniels> Srinath, do you want to slowly walk through the flow from the HttpReceiver? [09:09]<Deepal> not one three chains fro in , out and fault [09:09]<Srinath> +1 [09:09]<Srinath> 1)request come to trasnport [09:09]<gdaniels> Deepal: let's get there as we're going through the flow, and talk about it when we hit it? [09:09]<Deepal> . [09:09]<Deepal> k. [09:10]<Srinath> 2) transport create mesage context [09:10]<Jaliya> One more aspect, how to handle the addressing related info through out the path [09:10]<Srinath> + message (OM) [09:11]<Srinath> shall we follow the path once and go to detail after [09:11]<gdaniels> ok, good so far [09:11] *** alek_s joined #apache-axis [09:11]<gdaniels> I think we should go into detail as necessary now [09:11]<gdaniels> because there might be places where the detail causes a slightly different path [09:11]<Srinath> yes while waliking when we hit the point :) [09:11]<gdaniels> right [09:11]<gdaniels> but if you want to do it the other way I'd be ok with that too.... [09:12]<gdaniels> up to you [09:12]<alek_s> hello sorry to be late (christmas shopping) [09:12]<Chinthaka> hi alek [09:12]<gdaniels> hi Alek! [09:12]<Jaliya> Hi Alek [09:12]<Srinath> 3) Transport reciver calls Engine.recive(Msgctx) [09:12]<gdaniels> s/recive/receive/ :) [09:12]<Srinath> yap [09:12]<Srinath> :) [09:13]<Srinath> 4) engine inside receive ask for service from the registry [09:13]<gdaniels> (alek, we're walking through the flow of control from the transport listener to handle a request through the engine) [09:13]<gdaniels> whoa [09:13]<gdaniels> I don't think that's what happens [09:14]<Srinath> glen do you think we should delay dispatching? [09:14]<gdaniels> I think the engine gets the name of the transport from the MC, and looks up the appropriate "in" handlers from the registry, and adds those to an ExecutionChain [09:14]<gdaniels> Srinath: yes, I think we have to for flexibility [09:14]<dims_> hi all [09:14] *** dims_ is now known as dims [09:14]<gdaniels> Then the engine adds all the "global" phases to the EC up through the Dispatch phase. [09:14]<Deepal> hi dims [09:14]<gdaniels> hi dims [09:15]<Chinthaka> hi Dims_ and dims [09:15]<Ajith> Hi dims [09:15]<Jaliya> Hi Dims [09:15]<Chinthaka> :) [09:15]<Srinath> glen:I was worrid becouse we do not need global/transport hnadlers to run if the service is not deployed [09:15]<gdaniels> so the EC at this point looks like [ transport_handlers, phase1_handlers, phase2_handlers, dispatch_handlers ] [09:15]<gdaniels> Srinath: yes we do, because those handlers might be the ones who know how to do dispatch [09:15]<alek_s> Glen: i can see it is deep down async correlations talk :) [09:16]<gdaniels> If you want to do dispatch via URL and URL alone, you can just put the URLDispatchHandler as the first thing on your transport in chain [09:16]<Srinath> glen: let take some senario .. say I come and call a WS that is not deployed [09:16]<alek_s> did anybody propose to use Future<> form util.concurrent to make client API easier? [09:16]<gdaniels> then if the service isn't deployed that first handler will throw an error [09:16]<gdaniels> alek: we're not talking about the client API [09:16]<gdaniels> This is a walk through a server request [09:17]<Srinath> do we need the global tranport handler to run even the service is not deployed? [09:17]<gdaniels> "global transport handler"? [09:17]<gdaniels> what's that? [09:17]<Srinath> global and trnasport :) [09:17]<gdaniels> oh [09:17]<gdaniels> we need at least one of them to run, yes [09:17]<gdaniels> because there's no concept of "which service is being invoked" outside of some handler [09:18]<Jaliya> So there will be handlers before the dispatch [09:18]<gdaniels> The fact that a URL maps to a service is not an Axis core thing, it's a Handler thing (like it is in Axis 1.X) [09:18]<gdaniels> yes [09:18]<gdaniels> handlers DO the dispatch [09:18]<gdaniels> URL dispatch will be the common case [09:18]<gdaniels> but you could also do SOAPAction-based dispatch, or dispatch by looking at the XML, or... [09:18]<Srinath> but if the serivce is missing do not we suppose to just fail [09:19]<gdaniels> yes [09:19]<gdaniels> but when that happens is dependent on the order of the deployed handlers [09:19]<gdaniels> for instance there might be a logging handler that's the first thing on your transport chain, that would ALWAYS run, then after that might be a dispatch-by-URL handler which could fail on bad URLs [09:19]<Srinath> then we are saying it it user's repossiblity to revoke them ? [09:20]<gdaniels> Not sure what you mean? [09:20]<Srinath> good example glen yap:) [09:21]<gdaniels> So if the dispatch handler fails, the log handler gets a revoke() (I actually prefer onFault(), since it's not always actually revoking anything... i.e. the log handler won't "unlog"...) [09:21]<alek_s> this ordering of handlerexecution does sounds like little workflow again :) [09:21]<Srinath> glen I mean then we say user should be caerful to handle the case of global handler executing without service and fail [09:21]<gdaniels> Srinath: handlers which require the service to be set should happen after the Dispatch phase. [09:21]<gdaniels> That's what the Dispatch phase is for, to make sure that someone (it doesn't matter who) has set the service in the MC by the time that phase ends. [09:22]<alek_s> including ability to declare BPEL-like fault hanlders on multiple nested levels of execution [09:22]<gdaniels> alek: Can you give an example of what you mean by that? Simple scenario? [09:22]<Srinath> ok glen I take it let us continue :) [09:22]<gdaniels> Srinath: +1, let's just get what Alek means here first [09:23]<alek_s> you delcare <sequnce> <invoke handndle or any other logic possibley delcare in WSDL portType> <correlations ...> <catch faiultName .. /> </invoke> [09:24]<alek_s> i am not saying it is thing to do for first version but maybe more procedural way to descrinbe fault handlers in BPEL-like XML could be easier ... [09:25]<gdaniels> interesting... I'd want to see a couple of fleshed out examples I think [09:25]<alek_s> see http://www-128.ibm.com/developerworks/library/ws-bpel/#faulthandlers [09:25]<gdaniels> can we go on now and you can mail about this later? [09:25]<alek_s> and loook for example with <faulthandlers> [09:25]<Srinath> glen does we have a object call trasnport,global at the EngineRegistry OR keep everything as Phases? [09:25]<Srinath> inside service [09:26]<alek_s> fault handler can be attache dot scope which is very close to what is handler chain [09:26]<Deepal> so glen : what u talk is o have a methods like ER.getGlobalHandlers().exceute(); [09:26]<gdaniels> Srinath: my view is this. a given MessageContext has a list of Handlers that it's going to execute. It's a linear chain, and that chain can be modified as the MC moves through the system. [09:26]<alek_s> (later there is example with <scope> <faultHandlers .. /> <invoke .../> </scope) [09:26]<Jaliya> Srinath :So far the tranport and global handlers have been executed and we have identified the service right ? [09:27]<gdaniels> So initially that chain only has the transport + global handlers on it [09:27]<Srinath> jaliya:no we have not idenfied the service yet [09:27]<gdaniels> Once dispatch happens and we know what service is being invoked, THEN the service handlers get added to the chain in the appropriate places [09:27]<gdaniels> as far as the engine is concerned it just keeps clicking forward in the execution chain unless there's a failure [09:27]<Srinath> glen: you mean when the mesage context is created engine add trsport and global handlers? [09:28]<gdaniels> make sense? [09:28]<gdaniels> Srinath: well, probably not when it gets created [09:28]<gdaniels> When engine.receive() is first called though [09:28]<Chinthaka> glen : what we thought was get the execution chain first and execute [09:28]<gdaniels> So the registry lookups all take place inside the engine [09:28]<Srinath> yap geln start of recive(..) [09:29]<gdaniels> Chinthaka: I think your concept of execution chain might be a little different than mine.... [09:29]<gdaniels> What I'm talking about is demonstrated (very simply, but the idea is there) in the EngineToy I built a while ago [09:30]<Chinthaka> engine asks for the execution chain and the Service will create the *whole chain* for engine [09:30]<gdaniels> But how does the engine know which service it is, Chinthaka? [09:30]<Jaliya> Shall we agree on one, So far the engine has created the chain with transport + global handlers and executed, when the engine.recieve() is called [09:31]<Srinath> and what engie does it 1) add transort and global handlers 2) execute the chain [09:31]<Chinthaka> ok, so what u say is transport and global handlers are added to the EC before dispatch, right ? [09:31]<gdaniels> Srinath: +1! [09:31]<gdaniels> that's all it needs to do [09:31]<Srinath> the chain will gow as it go foward [09:31]<gdaniels> yes [09:31]<gdaniels> yes [09:31]<gdaniels> :) [09:31]<Srinath> by dispatching phase [09:32]<Srinath> :) cool [09:32]<gdaniels> service better have been set at the end, since the Dispatch postcondition checks it [09:32]<gdaniels> if it hasn't been set, the Dispatch phase fails [09:32]<gdaniels> but we don't care WHICH handler set it [09:32]<Srinath> +1 [09:32]<gdaniels> so it's very flexible [09:32]<Chinthaka> ok, I agree [09:32]<Jaliya> +1 glen [09:32]<Deepal> yep [09:32]<gdaniels> OK, so now we're at the end of the dispatch phase, and the service HAS been set [09:33]<alek_s> what about WS-RM? [09:33]<gdaniels> so the service-specific handlers have already been added to the ExecutionChain [09:33]<gdaniels> Alek: great Q [09:33]<alek_s> if message is out of order there will be no service called but message just stored for later [09:33]<gdaniels> two options as I see it [09:33]<gdaniels> either WSRM handler is in the global chain, in which case it might run before the service is dispatched [09:34]<gdaniels> or WSRM hadnler is service-specific in which case it runs after dispatch [09:34]<gdaniels> but in either case we have the ability to pause the MC and store it for later restart [09:34]<Jaliya> ok, that is fine, only concern is the ordering [09:34]<Jaliya> Ah, ok as long as we have "pause" button displayed, we can do it [09:35]<gdaniels> Jaliya: ordering just makes sure that the restarts of the paused MCs happen in the right order [09:35]<alek_s> that is tricky as we need to worry how to store MC for longer time - we do not want to loose messages (and processing pipeline state) when engine is restarted? [09:35]<gdaniels> Although we need to make sure that we can send an HTTP 202 Accepted when we "pause" I think...? [09:35]<gdaniels> Alek: yes, we need to get the details right [09:36]<gdaniels> There are a few tricky parts to handling RM right [09:36]<alek_s> moreover one will need to "restart" message chain processing and that includes all transport context so response can be send with correct security etc. [09:36]<gdaniels> I don't think we need to deal with them all right now, just get a sense that the architecture will be able to grow to handle it [09:36]<gdaniels> alek: explain? [09:36]<Srinath> yap back to basic glen:how we store the tranpsrt and global handlers in the Registry? (we have trnsport and global obj ) or we have them as phases (where?) [09:37]<gdaniels> Srinath: Transports have their own registry area, those are just stored by name. All the rest are just phases. [09:37]<alek_s> when message finally arrives that is in order other waiting messages needs to be processed by continuing execution of "paused" pipelines [09:37]<alek_s> but there is no longer original thread or connection that initiated processing [09:38]<gdaniels> alek: yes, but security stuff as well as anything else we need has been serialized/stored with MC [09:38]<alek_s> current thread and connection wil lbe different [09:38]<Srinath> +1 glen:we talk about the deploytime phase resolution how sahll we match it here? [09:38]<Srinath> I seen the possibilites need to clean it up:) [09:39]<gdaniels> alek: yes, so we need a way to switch contexts. [09:39]<alek_s> i think there is need for easy to use Engine API that allows programmatic control over handler chains their execution - that is more than just ability yo pause and resume pipeloine execution [09:39]<Jaliya> Alek, let's clarify, what you mean is when we pause a MC, and the if the incoming thread is over, then there should be some one to drive the rest am I right? [09:39]<alek_s> i think there are also case when handler will want to build its own handler chain [09:39]<alek_s> for exmaple in WS-RM to send ack messages [09:40]<gdaniels> Srinath: the engine has a list of two things - Phases and Handlers. Phases are deployed in a particular order, and then Handlers can identify themselves as being in a phase [09:40]<gdaniels> alek: wouldn't it just use the client API for that? [09:41]<Srinath> phases are improved HandlerChains at the engine? [09:41]<gdaniels> Phases need to somehow be associated with the correct pre/post conditions. I did this with a specialized Phase class (DispatchPhase, for instance), but we could also do it with handlers that run first/last [09:41]<gdaniels> Srinath: something like that, yes [09:42]<Srinath> then shall we say message context have 1)Execution chain [09:42]<Srinath> 2)Excution chainhas phases [09:42]<Srinath> 3)phases has handlers [09:42]<gdaniels> +1 [09:43]<Srinath> :) next glen: how should we preservice the deploy time ordering? [09:43]<Srinath> preserve [09:43]<gdaniels> Example? Not sure what you're asking... [09:44]<Srinath> glen: we resolve 90% of the handler order at the deploy time [09:44]<Srinath> but the message context is run time [09:44]<gdaniels> I'm not sure it's 90% [09:45]<Srinath> we want to stored the orderd handlers somwhere so they can dump in to message context at run time [09:45]<Deepal> glen : from where that global and transport hadnlders come [09:45]<gdaniels> we do that via phases [09:45]<Deepal> i mean weher we have spechify them [09:45]<gdaniels> right - we know the order within a given transport for sure [09:45]<Deepal> specify [09:45]<gdaniels> then we know the order for the global stuff [09:45]<Srinath> glen:I thought we said it 99% deploy time reolution before :) [09:46]<gdaniels> but then we add the service, and those handlers get added at dispatch time [09:46]<Srinath> glen:to which extent we do the deploy time handler ordering? [09:46]<Deepal> yes Srinnath we said like that [09:46]<gdaniels> plus we discussed maybe letting Handlers programatically change ordering too [09:47]<Jaliya> our future BPEL engine ;) [09:47]<gdaniels> So maybe the way to answer your question is this - when the engine asks the registry for the Transport, it gets a chunk of handlers. [09:47]<gdaniels> ALL those handlers as a unit get added to the ExecutionChain [09:47]<gdaniels> then the engine asks for all the global handlers, which consists of a variable number of Phases up to and including Dispatch [09:48]<gdaniels> all those handlers also get added to the EC [09:48] *** chathura joined #apache-axis [09:48] *** dims quit FreeNode : Remote closed the connection [09:48]<gdaniels> so now we've got [transport, phase1, phaseN, Dispatch] in the EC [09:48]<gdaniels> make sense? [09:48]<Jaliya> Yes [09:48]<Deepal> I think now we talk something similar to commonEcecutor what we discussed long time ago :: [09:48]<Srinath> glen EC? [09:48]<Deepal> :( [09:49]<gdaniels> once anyone sets the service, we then get [transport, phase1, phaseN, Dispatch, service1, service2, provider] [09:49]<alek_s> what is common executor? [09:49]<gdaniels> ExecutionChain [09:50]<gdaniels> the provider is the end of the road [09:50]<Srinath> glen: we decide we store the ordered transport handlers in transport +1 where we store te ohter ordered handlers? [09:50]<Jaliya> glen, I thought when the dispatching is done, we don't have transport and global anymore? [09:50]<Srinath> alek CommonExecuters are long forgotton! [09:50]<alek_s> what is its purpose? [09:50]<gdaniels> Jaliya: depends on when it gets done - if it's the first handler in the transport, there is still probably some transport work to do. :) [09:51]<gdaniels> Srinath: There is a registry of Phases, plus configuration for the engine which says what order they come in. [09:51]<Srinath> glen: mean they are in EngineResgitry? [09:51]<gdaniels> yes [09:52]<Srinath> +1 [09:52]<Srinath> glen:I belive phases can not overlap? [09:52]<Deepal> finally we are going to do run time odering , won't it be slow donwn the perpormance ? [09:52]<Chinthaka> alek : CommonExecutor was the name given to the trio Transoprt, Global and Service. We abandoned that thing :) [09:53]<Srinath> they are like HandleChains.. one after other [09:53]<gdaniels> Srinath: they cannot overlap that's correct [09:53]<gdaniels> (I think) [09:53]<gdaniels> Deepal: I don't think it'll slow things down much if we do it right. It's just putting together pre-built lego blocks. :) [09:54]<Srinath> +1 I think the in flow is quite done [09:54]<Srinath> we got to look at the out flow [09:54]<Jaliya> wait, before that shall we see what happen in the provider [09:54]<gdaniels> Well that involves one more piece of in flow [09:55]<Jaliya> I mean we need the same to happen when a message is recieved by the client as a response [09:55]<gdaniels> For the HttpReceiver, which is on a single thread, it has to put the HttpSender into the MessageContext as the "responder" [09:55]<Srinath> +1 [09:56]<gdaniels> Jaliya: we need to cover the client cases in general too - we discussed all this in Sri Lanka, but it's good to go over it again, so we can turn it into real code. :) [09:56]<Jaliya> glen: yes [09:56]<chathura> well rather than having entirely runtime ordering i would prefer to have a deployment time thing , if we wont we can keep room for runtime order changing [09:56]<alek_s> why not encapsulate chain ordering (registry and friends) into OrderingInterface (following Strategy pattern) so user can choose how handlers ordering should be done? [09:57]<chathura> reason is i dont think the runtime ordering is a very frequent use case is it? [09:57]<Chinthaka> glen : I will send an email to mailing list about putting the transport specific stuff to MC and how to use addressing for that [09:57]<Srinath> glen shall we have a reciver infront of provider which handle the sync/async aspects? [09:57]<gdaniels> alek: I'm not sure how that would work, and it sounds perhaps a little too much mechanism. :) [09:57]<Srinath> + in/out aspects [09:58]<alek_s> for start you have SimpleOrederingAllInDeploymentStrategy [09:58]<alek_s> used by engine to figure out order in which handlers are executed [09:59]<gdaniels> Srinath: Well, let's think about this. For one-way messages, there's no response, but there might be faults. [09:59]<gdaniels> (one-way is simplest case) [09:59]<alek_s> then user can provide their own strategies and interact with engine when setiing how handlers are executed [09:59]<alek_s> (this encapsulates complexity of hndlers ordering inone place that does just that) [09:59]<gdaniels> So we need some kind of "faultDeliveryChannel" or something which is the place faults go [10:00]<gdaniels> We also need a "replyDeliveryChannel" (or "Responder") which is the place where replies go [10:00]<Srinath> glen: ideas is keep he provider as 1.1 symantics .. recivers handle inout/sync/async by changing reciver we can meke service sinc/async [10:00]<gdaniels> alek: I'm not sure that's something you can pull out of the engine and still have the engine be useful... [10:00]<alek_s> if message is really one way message that it has neither response nor fault right? [10:00]<gdaniels> alek: We have one-way-with-fault MEPs in WSDL 2.0 [10:01]<Srinath> glen:about faults we can have a fault flow .. with a execution chain and just like a outflow [10:01]<gdaniels> Makes a lot of sense - message is HTTP request, then you either get 202 OK or 500 + fault [10:01]<gdaniels> Srinath : yes, exactly [10:01]<alek_s> glen: it woul dmake engine easier to understand if you have part deling with ordering algo separated (and that is main point of using Strategy pattern) but i am not sure how feasible it is ... [10:02]<gdaniels> alek: I'm not sure that it would actually make it easier to understand, since I think a lot of what the engine *is* is the handler execution model [10:03]<gdaniels> Srinath: could you explain the sync/async thing? [10:03]<alek_s> then it is not one-way messaage it is really MEP [10:04]<Srinath> glen: have a reciver and put sync /async code in the reciver (starting new threads ect) [10:04]<gdaniels> alek: for "real" one-way (fire and forget), there still may be faults and we may still want to direct them somewhere within our own system, even if they don't get transmitted [10:04]<alek_s> difference between 'http://www.w3.org/2004/08/wsdl/in-only'. and http://www.w3.org/2004/08/wsdl/robust-in-on [10:05]<gdaniels> Srinath: Tell me how that works - example? [10:05]<alek_s> http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#patterns [10:05]<gdaniels> alek: ya [10:05]<alek_s> \so in former there is no faults [10:05]<Srinath> glen see the code org.apache.axis.impl.receivers.* [10:05]<alek_s> in later there can be fault [10:05]<gdaniels> alek: no *transmitted* faults [10:05]<gdaniels> system can still generate them [10:06]<Srinath> geln:look at SyncInoutReciver [10:06]<Jaliya> Receiver is infront of provider in the server side, whcih will accept the message after the EC [10:06]<alek_s> glen: whe you say fault i think about message - i think exception when something happens inside EC that may be passed into fault handler chain (or not) [10:07]<gdaniels> Srinath/Jaliya: ok, looking [10:07]<Jaliya> Receiver will use different providers, e.g. java or pure XML etc.. [10:08]<gdaniels> uh [10:08]<gdaniels> so a Receiver is just something that decides whether to invoke the provider on the same or a new thread? [10:08]<Jaliya> yes [10:09]<Jaliya> It will know the message patterns [10:09]<Srinath> it can handle MEp aspects as well I think [10:09]<Jaliya> I mean IN-ONLY, IN-OUT etc [10:09]<gdaniels> how does it do that? [10:09]<Srinath> idea is seperate provider and sync/async + MEPS logic [10:10]<gdaniels> it's the provider that knows the MEPs, I think [10:10]<Srinath> e.g. there may be oneway onely reciver that invoke the provier and forgets [10:10]<Jaliya> It should be a deployement decision, I think [10:10]<gdaniels> hm [10:11]<gdaniels> OK, this gets into a pretty interesting discussion, I think. [10:11]<Deepal> u mean selecting provider at the deployemnt time ? [10:11]<gdaniels> But we're already over time... :( [10:11]<Srinath> let say differant level of providers (one who know MEPS, one who know how to execute impl ect ) [10:11]<Srinath> glen do you got to run? I canmanage few for mins [10:12]<gdaniels> I can stay another 15 min or so, but should go after that [10:12]<Srinath> :) if we do not decided after that let discuss in the dev list [10:12]<Jaliya> Yes [10:13]<gdaniels> So a provider has a concept of whether its doing RPC type stuff or not, right? I.e. it knows if it's going to return something or not [10:13]<Srinath> glen what do you think about the Reciver (provder who knows MEPS ;) ) [10:13]<Deepal> glen : ragrading Clinet API thing , lets us discuss that using mails : [10:13]<gdaniels> Srinath: not sure yet. :) [10:13]<Deepal> it is too late to discuss that in next week [10:13]<Jaliya> Yes glen provider is specific to the impl [10:13]<Srinath> glen +1 yas provider know doc lit ect (about impl invocation) [10:14]<gdaniels> So in particular, I would expect the provider to be the one that calls sender.sendResponse(response) [10:14]<gdaniels> or just send(response) [10:14]<Jaliya> users can write it, Receivers are corresponding to the MEPs, and also we can have a receiver at the client side as well wchich will handle the callbacks [10:14]<Srinath> we cam mke that is reciver call send [10:14]<gdaniels> so what does the provider do with the value it gets back from the Java method? [10:15]<gdaniels> Object ret = method.invoke(deserializedArgs); [10:15]<Srinath> then by changeing reciver keeping provider we can me a invocation sync <->async [10:15]<gdaniels> then what? [10:15]<Jaliya> I will explain [10:15]<Srinath> glen: send it to mesaeg context [10:15]<Srinath> set it to mesage context [10:16]<Jaliya> If the receiver is sync, then it will wait for the provider's response bloking the current thread [10:16]<gdaniels> where in MC? [10:16]<Srinath> as message [10:16]<Jaliya> if the receiver is async type then it will start a new thread of its own and wait for the provider's response and start a new client flow [10:16]<Srinath> wrap by OM (directly /indirectly) [10:16]<Jaliya> to send the response (if any) [10:17]<gdaniels> hm.. ok, I think I see where you're going. [10:17]<Srinath> :) [10:17]<Jaliya> :) [10:18]<gdaniels> Sounds OK, need to think about it a little. :) [10:19]<Jaliya> Yes, agreed, send your thoughts about it :-) [10:19]<Srinath> glen can you think about it and put a note to dev list ? [10:20]<gdaniels> so the code that currently says sender = new Sender() in the InOutSyncReceiver will be replaced with sender = msgContext.getSender() [10:20]<gdaniels> Srinath, Jaliya: Yes, definitely. [10:20]<gdaniels> Can we make the other changes we talked about earlier too with respect to the ExecutionChain and the engine behavior? [10:21]<Srinath> glen:yes we can do that (now sender get info from the mesage context to work ) we can set the send in msgctx itself [10:21]<Jaliya> Glen please explain that msgCtx.getSender() part [10:21]<Chinthaka> msgContext.getSender() ?? [10:21]<Srinath> glen: I will change the engine to changes we discuss and get back! [10:22]<gdaniels> Srinath: +1, please get in touch and/or look at EngineToy for ideas [10:22]<gdaniels> The getSender part is just about the fact that the Sender object has been put in the MC by someone who knows how to send - i.e. the HttpReceiver knows how to send a response back out the HTTP connection [10:22]<Srinath> sure glen and will get back to you for any clarification if needed :) [10:23]<gdaniels> The WS-Addr handler knows how to send the reply to the "wsa:ReplyTo" address, etc. [10:23]<Jaliya> oh, ok. got it [10:23]<gdaniels> those guys will put a Sender in place [10:23]<Jaliya> You mean TransportSender in it [10:23]<gdaniels> I'm not sure it's transport-specific [10:24]<gdaniels> need to go through some more use-cases [10:25]<Jaliya> ok, we too, If some one in the request path adds a sender, then we may think the message path as req/res again? [10:25]<gdaniels> not necessarily [10:25]<Chinthaka> glen : isn't it enough to put some addressing specific info in to MC to do this [10:25]<Jaliya> but we can carry the info need to send the response( if any) [10:25]<gdaniels> yes [10:25]<Chinthaka> I mean wihout putting a "Sender" ? [10:25]<Srinath> glen:sender is one who strt the response flow? [10:25]<gdaniels> yes to Jaliya, not to Eran [10:26]<Chinthaka> :( [10:26]<Jaliya> :) [10:26]<gdaniels> Srinath: yes, I think so. Need to go into more detail / talk this out more. [10:26]<gdaniels> Eran: I'm not sure what you meant [10:26]<Chinthaka> its like this GLen [10:27]<Chinthaka> TransportReciever put some info in to MC [10:27]<Chinthaka> like To stuff [10:27]<Chinthaka> if there is a Addressing handler [10:27]<Srinath> glen:I think it is not hard to change it pattern we decided even later .. let discuss looking at the code [10:28]<Jaliya> Yep, it may be late for you glen [10:28]<Chinthaka> it will replace those values in the MC [10:28]<gdaniels> Eran: Yes, that sounds right [10:28]<Chinthaka> then the transport sender has all the info from the MC [10:28]<gdaniels> It's just that the "to stuff" is envisioned as a Sender/Responder/whatever class [10:29]<Chinthaka> oki [10:29]<Chinthaka> I start a thread on this in the mailing list, after this chat [10:29]<gdaniels> Let's try to focus on the rest of this use case (i.e. handing MEPs, response) on the list [10:29]<gdaniels> Eran: +1 [10:29]<gdaniels> OK, I'm gonna head to bed, guys. Good chat!! [10:29]<Chinthaka> Good night [10:29]<Srinath> glen I think have put that logic at tranport level will pull them up to sender ! [10:30]<Chinthaka> BTW : is Alek here ? [10:30]<gdaniels> Srinath: k [10:30]<Srinath> good night glen:) [10:30]<Jaliya> Good Night Glen and Alek [10:30]<gdaniels> good night, everyone, talk to you tomorrow :) [10:30]<Chinthaka> Alek ??? [10:30] *** gdaniels is now known as glen-zzzz [10:31]<Chinthaka> who gonna post the chat log this time, Alek must have far asleep [10:32]<alek_s> YES [10:33]<Chinthaka> ahh, r u posting the log ?? [10:33]<alek_s> please post it to mailing list and to wiki [10:33]<alek_s> i do not have first 10 minutes [10:33]<Chinthaka> ok [10:34]<Chinthaka> BTW : I need to have a chat with u regarding addressing [10:34]<alek_s> let do it next week [10:34]<Chinthaka> please just drop a hi when u r free :) [10:34]<Chinthaka> in Yahoo [10:34]<alek_s> i will be travelling friday/saturday [10:34]<alek_s> ok [10:34]<alek_s> will do [10:35]<alek_s> but if i do not just send me email remainder [10:35] *** dasarath left #apache-axis : [10:35]<Chinthaka> ok thx and byee [10:35] *** chathura left #apache-axis : [10:36]<alek_s> bye [10:36] *** alek_s quit FreeNode : "Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]" [10:36]<Srinath> bye alek (hope you had sucesseful x-mas shopping ;) ) [10:36]<Srinath> bye [10:36] *** Chinthaka quit FreeNode :