Hi Kasun, In the axis2 level, we can see "sendStacktraceDetailsWithFaults" and "DrillDownToRootCauseForFaultReason" parameters. Can't we use those parameters to propagate the errors happens in the transport layer?
Thanks. /Susankha. On Tue, May 17, 2016 at 11:47 AM, Kasun Indrasiri <ka...@wso2.com> wrote: > For most of E3 type errors (such as timeout, connection closing etc.) we > do invoke fault sequence (if not specified default fault sequence) of the > associated mediation logic. However, the current design doesn't not > guarantee that all possible errors are handled in that way. That's why we > need a generic fault handling logic in the transport layer, so that we > propagate all errors. > > On Mon, May 16, 2016 at 11:19 PM, Srinath Perera <srin...@wso2.com> wrote: > >> >> >> On Tue, May 17, 2016 at 11:28 AM, Isuru Udana <isu...@wso2.com> wrote: >> >>> Hi Srinath, >>> >>> On Tue, May 17, 2016 at 11:13 AM, Srinath Perera <srin...@wso2.com> >>> wrote: >>> >>>> Kasun, what is the answer? >>>> >>>> Problem is that client does not know when the result will come back. >>>> >>>> >>>> 1. If client call start only a one sequence, and it has failed, >>>> then we can stop the client connection. >>>> 2. If client call has started multiple sequences, error handler >>>> should decide what to do. We should provide killCurrentCall() kind of a >>>> sequence to let error handler tell engine to cleanup. >>>> 3. If all fails, then timeout will handle that. >>>> >>>> WDYT? >>>> >>> I am not sure whether I got your idea correctly. >>> IMO, irrespective of number of sequences in the message flow, we should >>> invoke the fault handler for all errors occurring at different layers and >>> at the fault handler we need to allow user to decide what's need to be >>> done. >>> >> >> Two concerns in this case >> >> 1. In default case, where no error handler has been defined, scenario >> should work and print correct errors. >> > Yes, it invokes the default fault handler. The problem is that if the > default fault handler just logs the errors does not respond client, the > client waits and holds the connection to ESB. We can easily fix this by > changing the default fault handler logic. > > 2. When, multiple threads or sequences has been started, we need to >> provide helper fucntion to stop cleanup other thread if user need to handle >> it. >> >> Yeah, this make sense when we have complex mediation logic that involves > multiple threads (such as iterate,clone etc.) > >> I am trying to address above two. >> >> >> >>> Currently for all the errors happens at the mediation layer, fault >>> sequence is getting executed. >>> But there can be situations where fault handler is not executed for >>> errors happens at the lower layers at the transport sender side. That is >>> the problem we need to test and address carefully. >>> >> Can we give java level callback for this case? >> > Yeah, I think we can use a generic callback object and use that across the > transport layer to invoke when any error happens. > >> >> >>> >>> Thanks. >>> >>> >>>> >>>> --Srinath >>>> >>>> On Tue, May 17, 2016 at 10:33 AM, Artur Reaboi <artur.rea...@egov.md> >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> >>>>> >>>>> Are there any workarounds recommended for E3 type of errors on current >>>>> WSO2 ESB 4.9.0? >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> *Artur Reaboi* >>>>> *Enterprise Architect | e-Government Center* >>>>> >>>>> Tel +373 22 250 487 |Mob +373 79 440 064 |Skype reaboi.artur >>>>> >>>>> >>>>> >>>>> *From:* Architecture [mailto:architecture-boun...@wso2.org] *On >>>>> Behalf Of *Kasun Indrasiri >>>>> *Sent:* marți, 17 mai 2016 00:07 >>>>> *To:* architecture <architecture@wso2.org> >>>>> *Subject:* [Architecture] Improving error handling at different >>>>> layers in ESB >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> ESB has to deal with different types of errors occurring at multiple >>>>> layers in ESB message flow. As depicted in the following diagram, there >>>>> can >>>>> be different places where an error could happen. >>>>> >>>>> >>>>> >>>>> At the moment, the current design doesn't seems to ensure that all >>>>> errors are propagated back to the other layers. For instance, if something >>>>> goes wrong at the target side (E3 type errors) there's no generic place >>>>> that all such errors are caught or handled and client may be holding up >>>>> the >>>>> connection to ESB. In most cases, such errors should be propagated to the >>>>> associated fault sequence and error handling happens in the fault >>>>> sequence. >>>>> >>>>> Therefore we need to carefully evaluate the possible places that the >>>>> errors can occur and handle them at an unified layer. >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Kasun >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Kasun Indrasiri >>>>> Software Architect >>>>> WSO2, Inc.; http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> cell: +94 77 556 5206 >>>>> Blog : http://kasunpanorama.blogspot.com/ >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> ============================ >>>> Srinath Perera, Ph.D. >>>> http://people.apache.org/~hemapani/ >>>> http://srinathsview.blogspot.com/ >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Isuru Udana* >>> Associate Technical Lead >>> WSO2 Inc.; http://wso2.com >>> email: isu...@wso2.com cell: +94 77 3791887 >>> blog: http://mytecheye.blogspot.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> ============================ >> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera >> Site: http://home.apache.org/~hemapani/ >> Photos: http://www.flickr.com/photos/hemapani/ >> Phone: 0772360902 >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Kasun Indrasiri > Software Architect > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > cell: +94 77 556 5206 > Blog : http://kasunpanorama.blogspot.com/ > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Susankha Nirmala Software Engineer WSO2, Inc.: http://wso2.com lean.enterprise.middleware Mobile : +94 77 593 2146
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
