Hi All, Tried some scenarios for these kinds of errors, found one when calling back-ends, Say back end goes down as soon as ESB connected to back end(before sending any messages to back end) then the flow breaks (won't go to any fault sequences or anything). So the client gets timed out. So created a public jira [1] and fix [2] for that issue.
I tried so many other scenarios (timeouting back end during back end request sends, terminate back end during varies parts of request sending etc)but only found the earlier mentioned issue. All the other connection related areas get captured when connection gets closed. [1] - https://wso2.org/jira/browse/ESBJAVA-4629 [2] - https://github.com/wso2/wso2-synapse/pull/557 Thanks, On Wed, May 18, 2016 at 3:33 AM, Susankha Nirmala <susan...@wso2.com> wrote: > 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 > > -- Rajith Vitharana Software Engineer, WSO2 Inc. : wso2.com Mobile : +94715883223 Blog : http://lankavitharana.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
