- [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 126.96.36.199/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: [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
[13:48] gdaniels: I'm gonna work on caching the introspection results in AxisOperation as soon as my site changes build correctly
[13:49] jaliya has joined
- [14:49] Deepal: we had a long discussion on RESPONSE_WRITTEN [14:49] dblevins has disconnected: "This computer has gone to sleep" [14:51] dblevins has joined [14:51] Deepal: finaly we conclude to have if statementy to check whether we are in the client side or server side [14:52] chathura: history repeats itself
[14:52] Deepal: [14:52] Deepal: I agree with you [14:52] Deepal: all the three Hackathon we had a long discussion on handler chain [14:52] Deepal: and flows [14:53] Deepal: any way that helpful to fix our issues [14:53] gdaniels: lol Chathura [14:53] Deepal: we can make sure , we have doen the right thing [14:53] chathura: of course [14:54] Deepal: may be you can jupm and help us
[14:54] Deepal: to fix JIRAs [14:55] chathura: i promise to have a look at the issues around 2744 tonight [14:56] chathura: dont know if i could really alocate time to fix
[14:58] Deepal: [14:58] Deepal: btw aftre long time we have most of the initial developer of Axis2 here in IU
[14:59] Deepal: only You and Ajith is missing [14:59] Deepal: and I forget Ajith will come here as well [14:59] chathura: yup i heard:( [15:00] dblevins has disconnected: "Leaving" [15:01] dblevins has joined [15:08] sanjiva_ is now known as sanjiva [15:09] sanjiva: good afternoon folks
[15:09] sanjiva: so .. I'm up trying to make up the final exam for my programming languages class :). Any bright ideas for questions? [15:12] gdaniels: i.e. programming language design? [15:12] gdaniels: or programming in various languages?
[15:13] srinathp: jaliya's brother is in the class .. he can give few Q I guess [15:13] chathura: prove lambda calculus and turing machines capture the same computational model [15:14] Chinthaka: can they do that? [15:15] chathura: think there are ppl who can:-D i am not one of them [15:16] jaliya: Concurrent programming book
[15:19] sanjiva: chathura: that's more computability material .. not PL class [15:20] sanjiva: but maybe just for fun I'll put that as an extra credit problem and see; instructors have to have fun sometimes! [15:21] chathura: think they will hate you forever . please dont mention my name
[15:22] sanjiva: It'll be my pleasure to attribute the question to the source [15:23] chathura: :-D
[15:32] Deepal: do we need to fix this https://issues.apache.org/jira/browse/AXIS2-2459 [15:32] Deepal: if not let's resolve that as wont fix [15:35] Chinthaka: well, let's keep it as a wish list [15:35] Chinthaka: it doesn't hurt anybody [15:35] Deepal: its meen we are not going to fix that [15:36] Deepal: after some times we will make that as wont fix , thats wt happen so far [15:37] Chinthaka: if some one is coming new to Axis2 and if they wanna do something, then these issues will help them to start something [15:37] Deepal: ok
[15:38] Chinthaka: JIRA is not only about bugs [15:38] Chinthaka: it has wish lists as well [15:38] Deepal: ok I mared that as a which and reduce the priority
[15:38] Deepal: next one https://issues.apache.org/jira/browse/AXIS2-2443 [15:39] Deepal: TCP is not a good transport in Axis2 [15:39] Deepal: its in experimental stage [15:39] Deepal: and I do not think any will use that [15:40] Deepal: any one will use it gdaniels: the question is what does someone have to do to make a new transport
[15:45] gdaniels: which you just answered
- [15:45] gdaniels: sure [15:46] gdaniels: so maybe we should consider moving the transports we've got except HTTP into library jars [15:46] gdaniels: ? [15:46] Deepal: I would say even HTTP into the same place [15:46] gdaniels: this gets into the packaging discussion we had ages ago [15:46] Deepal: axis2-tansport.jar [15:47] gdaniels: i.e. axis2-minimal.jar has purely core stuff, no transports [15:47] Deepal: which will have all the tarnsport we have [15:47] Chinthaka: I hope we are talking about things that will happen after this week, right? [15:47] gdaniels: axis2-small.jar has HTTP but nothing else [15:47] Deepal: oh that rasied a good q [15:47] Deepal: abt our packaging [15:47] gdaniels: yes Chinthaka, but I'd like to record it as a JIRA maybe [15:47] Deepal: I think its good idea to talk ant that too [15:47] gdaniels: 1.4 timeframe
[15:47] gdaniels: for now bloated jars are the least of our problems
[15:48] Chinthaka: Glen : +1. But make sure you get permission from Deepal as he might mark it as won't fix later [15:48] gdaniels: lolol
[15:48] Deepal: [15:52] Deepal: hmm , I wonder its the good idea to ask this q
[15:52] Deepal: what if intergarte addressing handlers in axis2.xml and remove addressing module [15:59] Chinthaka: Deepal, I think the best place to ask this question is mailing list [16:00] gdaniels: Deepal, I'm really torn about that one
[16:00] Deepal: [16:00] Deepal: alredy done
[16:00] gdaniels: I think it makes sense, but addressing.mar is a great example of eating our own dog food. [16:00] Deepal: there I m thinking as user [16:00] Deepal: if I want to have session support , asyn invocation I need to go and add addressing module [16:00] gdaniels: yep [16:00] gdaniels: oh [16:00] gdaniels: well, that's fixable
[16:01] Deepal: and need to create ServiceClient with that [16:01] gdaniels: STOP using addressing for sessions
[16:01] gdaniels: [16:01] Chinthaka: see this is what I always say [16:01] gdaniels: asy invocations, though, yes. [16:01] Deepal: forget abt the session [16:01] gdaniels: yap [16:01] Chinthaka: the answer is not getting addressing in to the core [16:01] Deepal: how abt the asyn invocation [16:01] Chinthaka: it is about module deployment easier [16:01] Deepal: just to have that we need to go and engage addressing [16:01] gdaniels: how do you make it easier Chinthaka?
[16:01] gdaniels: put your mar on the classpath? [16:01] Deepal: and to do so we need to create service client with repository [16:02] Deepal: ??? [16:02] Chinthaka: well first [16:02] Deepal: I think addressing is core part of Axis2 [16:02] Chinthaka: Deepal why do you wanna get addressing in to core [16:02] Deepal: its like Dispatchers in the Axis2 [16:02] Chinthaka: no it is not [16:03] Deepal: for me addressing handlers and Dispatchers are the same [16:03] Chinthaka: core can not work without dispatching [16:03] Chinthaka: but core can work without addressing [16:03] gdaniels: you can't easily do two channel req/resp without addressing [16:03] Deepal: and you have agree with me we have lot of dependcey in core on addressing [16:03] Chinthaka: Glen agree [16:03] Chinthaka: but lots of people still use sync [16:03] gdaniels: aside from that, it's not core [16:03] jaliya: yes [16:03] Chinthaka: and remember people are still satisfied with addressing [16:04] gdaniels: the MODEL is core (the dependencies Deepal is talking about) [16:04] Chinthaka: which mainly support sync invocations [16:04] jaliya: they all say, sync works [16:04] gdaniels: but not the headers, or the handlers [16:04] jaliya: and once they try async stuff they face problems [16:04] sanjiva: OT question: does anyone have Chathura (staff @ MRT)'s email addr?? I need to send him the question [16:04] jaliya: and complains [16:04] jaliya: most because of the configuration [16:04] Deepal: sanjiva ????
[16:04] sanjiva: sorry guys [16:04] Deepal: cool [16:04] sanjiva: I did say "OT" at the front ....
[16:04] Chinthaka: [16:05] gdaniels: lol [16:05] Chinthaka: what I would say is make module deployment easier or understandable to the users
[16:05] Deepal: when you type OT I though Oxygen Tank [16:05] sanjiva: oh sorry! Off Topic! [16:06] sanjiva: if addr is core, how do we prevent those pesky headers from appearing by default? or are u suggesting that we should leave it on for
requests by default?
- [16:06] sanjiva: (for responses we can sense and see .. if the req had addr then we put it too) [16:06] sanjiva: s/addr is core/addr is engaged by default/ [16:07] Chinthaka: woohoooooooooo [16:07] Chinthaka: I just won the war !! [16:07] sanjiva: not just the battle but the whole war?? wow
[16:08] Chinthaka: hehe [16:08] sanjiva: give a call to GB; he needs some strategists .. [16:08] Chinthaka: I was kidding [16:08] Chinthaka: GB? [16:08] jaliya: Gotabya
[16:08] sanjiva: no the democratically elected (and democratically re-elected) US president [16:08] jaliya: ?
[16:08] jaliya: [16:08] sanjiva: dumbya [16:09] sanjiva: ok I'll shut up; this is what happens when its nearly 1:45am and the exam is in a few hrs and I am still not done.
[16:10] Deepal: ok developers won , user lost
[16:10] srinathp: [16:10] Deepal: ist should be the other way round
[16:32] srinathp: Shall we do no fix for https://issues.apache.org/jira/browse/AXIS2-1134. my last comment was <snip>I purposed not to support
this. It is not clear how Output stream is to be stored (serialized), and even we though able to do it, OS resources will not be avalible for ever. Supporting this will be
big hassle and it will lead to many future problems.</snip>
- [17:00] chathura: ok guys i am done for the day [17:01] chathura: see you all tomorrow [17:02] chathura has disconnected
[17:44] srinathp has disconnected: "ChatZilla 0.9.78.1 [Firefox 188.8.131.52/2006073115]"