Hi Chamikara, If you are doing work that is a critical part of the interaction, and where an error needs to be communicated back to the requestor, then that work should be completed before the response message (assuming that the operation isn't one-way) is sent, so that that fault can be returned as the response -- we don't have a MEP that supports any other style of interaction (e.g. sending a response followed by a fault.) This can either be accomplished by placing the logic in the output flow (for req/rsp) or placing the entire req under a transaction.
-Bill On Mon, 2007-03-12 at 20:36 +0530, Chamikara Jayalath wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
