Hi Bill, What do u think of the use case where some handler want to do some post-MR work. But still it may want to let the client know of any exceptions that occured (through a SOAP fault).
And as David sugested, we can make sure that the flowComplete of all the handlers get called by enclosing it's invocation within a try block and sending only the very first exception to the client. Chamikara On 3/12/07, Bill Nagy <[EMAIL PROTECTED]> wrote:
I purposely did not allow flowComplete(...) to throw an exception, as I have no idea what the runtime could possibly do if that occurs seeing as how all of the "important" work will have already been done and the connections most likely terminated. I would prefer that we leave the interface explicit in this manner (i.e. not make handlers think that the runtime can/will do something useful with an exception by specifying it in the interface) unless we have a valid use case that says otherwise. I believe that given the semantics of what flowComplete(...) is trying to accomplish, that simply logging the exception is a valid means of dealing with it. -Bill On Mon, 2007-03-12 at 15:52 +0530, Chamikara Jayalath wrote: > Hi David, > > On 3/12/07, David Illsley <[EMAIL PROTECTED]> wrote: > So it's valid to do post MR work in flowComplete but swallow > exceptions if they occur. The clearest example (in my mind) is > removing a transaction from a thread. That itself could have a > failure > but it shouldn't prevent the other flocwCompletes bing > called. > > From the original proposal: > > (If the flowComplete(...) method > throws an exception, the rest of the handlers must still have > their > flowComplete(...) methods invoked.) > > We could wrap the calls to flowComplete with a catch block, > ensure all > the flowCompletes are called and then throw a new exception > with the > rootCause of the fist exception caught. > > > That looks like a good option. Will try to implement that. > > Chamikara > > > > David > > On 12/03/07, Chamikara Jayalath <[EMAIL PROTECTED]> wrote: > > Hi David, > > > > See your point. We need to clearly define the semantics > here. With my > > change, once an exception get thrown the rest of the > handlers will not be > > called. > > > > I was using the flowComplete method as a way to do some post > MR work (both > > here and in Sandesha2). If we do not throw out an exception, > that should not > > be recommended. (In that case I will revert my change). > > > > > > Chamikara > > > > > > On 3/12/07, David Illsley <[EMAIL PROTECTED]> wrote: > > > Hmm, I'm not sure that an exception there is the right > thing to do... > > > but I'll take a look at the code and get back to you. > > > > > > I do have a concern that the whole point of flowComplete > is to let > > > handlers get a callback when the flow is complete. If one > of them > > > thows an AxisFault, will the remaining handlers get > flowComplete > > > called? > > > > > > David > > > > > > On 12/03/07, Chamikara Jayalath <[EMAIL PROTECTED]> > wrote: > > > > Yep. (just committed this). > > > > In the clustering impl I needed to do some replication > stuff in the > > > > flowComplete method. Didn't want to eat up exceptions > with only a log > >:-) > > > > > > > > Chamikara > > > > > > > > > > > > > > > > On 3/12/07, David Illsley < [EMAIL PROTECTED]> > wrote: > > > > > > > > > > Hi, > > > > > I imagine there's a reason why you want to do this...? > > > > > David > > > > > > > > > > On 11/03/07, Chamikara Jayalath < > [EMAIL PROTECTED]> wrote: > > > > > > Hi All, > > > > > > > > > > > > Currently the Handler.flowComplete method does not > throw any > > exceptions. > > > > > > Shall we change this to throw out an AxisFault ? > > > > > > > > > > > > Chamikara > > > > > > > > > > > > > > > > > > > > > -- > > > > > David Illsley - IBM Web Services Development > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > > > > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > David Illsley - IBM Web Services Development > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > -- > David Illsley - IBM Web Services Development > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
