Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The following page has been changed by Deepal: http://wiki.apache.org/ws/FrontPage/Axis2/hackathon_12_06 New page: [09:18] hperera has disconnected: Client Quit [09:20] Srinath_ has joined [09:58] Deepal: now wre are dicsussing abt mesage flow [09:59] Deepal: in the client side [10:00] saminda has joined [10:01] azeez has joined [10:14] Srinath_ has disconnected: "ChatZilla 0.9.78.1 [Firefox 1.5.0.5/2006073115]" [10:18] srinath has joined [10:18] srinath has disconnected: Client Quit [10:20] srinathp has joined [10:40] Deepal: good discussion [10:40] Deepal: abt client flow [10:40] Deepal: we found an issue [10:40] Deepal: when we send the mesage using two-channel blocking [10:41] Deepal: we are not hadling when there is a soap fault which come on the back channel [10:41] amila_suriarachc has joined [10:43] saminda has disconnected: "Ex-Chat" [10:45] azeez: hi guys [10:46] azeez: Is it possible to introduce an exception to the flowComplete method of a Handler [10:46] Deepal: hmm [10:46] azeez: i.e. flowComplete throws AxisFault ? [10:46] Deepal: may be [10:46] davidillsley: hi azeez [10:46] davidillsley: we've been round that before [10:46] Deepal: btw what we are going to do with that [10:47] azeez: hi david [10:47] gdaniels: you want flowComplete() throws AxisFault? [10:47] azeez: here is my scenario [10:47] davidillsley: it's important that all the flowCompletes get called [10:47] gdaniels: I agree w/Deepal - what do you do with it? [10:47] azeez: In the clustering implementation, there is a REplicationHandler [10:48] azeez: so I replicate the state on flowCompletion [10:48] azeez: something can go wrong at this phase, and the client has to be notified about this [10:49] azeez: was thinking whether a fault can be thrown from the flowComplete method, so that a SOAP Fault can be sent to the client [10:49] gdaniels: I'm not sure that's a good use of flowComplete() [10:49] gdaniels: I would think that flowComplete() would mean "no, really, the flow is DONE. All messages have already been sent, resources are ready to clean up, etc" [10:49] azeez: hmm.... [10:50] azeez: may be the call for replication has to go elsewhere in the code, possibly into the core, not another handler [10:51] davidillsley: so we could modify the code that calls flowComplete to catch any exceptions, ensure all the flowCompletes are called and then re-throw the first exception it got [10:52] azeez: david, I was also thinking of something in that line [10:52] gdaniels: so when are you currently calling this, Afkham? After the MessageReceiver has been invoked on the inbound flow but before the outbound flow has happened? [10:52] davidillsley: that maintains the contract of flowComplete and if the transport or MEP has something it can do with the fault (likely given the relative positions of the engine and transport) then it'll deal with it [10:53] azeez: the ReplicationHandler instance is placed on each flow [10:53] azeez: depending on the MEP, a particular instance will get called [10:54] azeez: e.g. for an in only mep, RH gets called on flowComplete of the instance in the InFlow [10:54] gdaniels: and for in/out? [10:54] davidillsley: here's a mail from a relevant thread (I don't know how to link to the thread) [10:54] davidillsley: http://marc.info/?l=axis-dev&m=117394114131797&w=2 [10:55] azeez: for in out, the flowComplete of the out flow RH gets invoked [10:55] azeez: see ReplicationHandler flowComplete method [10:55] gdaniels: so after the outflow is complete, hasn't the response already been sent? [10:55] gdaniels: i.e. it's too late to inject a fault anyway [10:56] davidillsley: if you look at that link, it looks like bill debunked my idea last time round and that you're right :-) [10:57] gdaniels: :) [10:58] azeez: david has a good point in his mail thread, how do we deal with exceptions that occur during flowComplete, which will actually occur in practice? [10:58] gdaniels: there's this great thing called log4j :) [10:58] azeez: :D [10:59] gdaniels: if an exception in flowComplete() puts us at serious risk, btw, you could always do something like shut off services, etc. [10:59] gdaniels: log a serious error, shut down a faulty service so it always returns a fault that says "unavailable" [11:01] azeez: ok.... I'll come up with some other mechanism to handle the Replication... looks like a handler is not the appropriate place to handle the replication [11:01] azeez: one other question.... there has been some API changes yesterday [11:04] azeez: removal of getEngagedModules [11:04] gdaniels: we've been discussing that here - it's going to be reverted [11:05] gdaniels: well, not really - I mean fixed to return AxisModule references everywhere [11:05] gdaniels: so it'll be back [11:05] azeez: the method getEngagedModulesNames is gonna be removed? [11:05] gdaniels: right [11:05] azeez: phew :) [11:05] gdaniels: :) [11:10] azeez has disconnected: "Leaving" [11:36] davidillsley has disconnected: Read error: 104 (Connection reset by peer) [11:38] sanjiva_ has disconnected: Read error: 60 (Operation timed out) [11:42] sanjiva_ has joined [12:12] ajith has joined [12:14] chathura has joined [12:23] jaliya_ has joined [12:40] gdaniels: Breaking for lunch - back in maybe 45 [12:41] gdaniels: (figure 1:30) [13:05] jaliya_ has disconnected: Read error: 110 (Connection timed out) [13:32] Deepal: I am working on fault handling [13:32] Deepal: when we send the req in two channel [13:33] Deepal: and we get the fault reseponse in the sending path [13:33] gdaniels: Game plan for the afternoon - everyone is going to work on JIRAs for a few hours [13:33] srinathp: Couple of comments on cleanups in client API [13:34] gdaniels: We'll paste which issues we're up to in here, and collaborate dynamically as appropriate (hey, that sounds like Alek's thing!) [13:34] Chinthaka has joined [13:35] srinathp: 1) shutdown input stream of the response - When service client return a response it can not shutdown the the input stream (and associated socket) because OM may not have read it so far. We support this by method cleanupTransport(), but we need to document it clearly. Also we decided we should change the method name, readCompleted(). [13:35] srinathp: 2) shutdown the transport Listener - service client cleanup can not shutdown the Transport listener as same transport listener (with configuration context). To handle this we need to add reference counting to transport listener manager. It is also good idea to allow grace wait for somebody else to reuse --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
