Hi Kasun,
Shall we list down types of issues you may think we haven't handled (I
need to get broader concept of this proposal)?
IMO for E3 level issues, we may have to think any missing pieces at
TargetHandler, because that would be the interceptor which communicates
with NIO i.e NHttpClientEventHandler for ESB -- > BE (when considering
pass through transport).
Anyway, I was under the impression that "exception layer" supposes to
capture any error that could happen through E3?
So, as I mentioned above list down those errors would be handy to take this
discussion forward.
*TargetHandler*
public void exception(NHttpClientConnection conn, Exception ex) {
ProtocolState state = TargetContext.getState(conn);
MessageContext requestMsgCtx =
TargetContext.get(conn).getRequestMsgCtx();
if (state == ProtocolState.REQUEST_HEAD || state ==
ProtocolState.REQUEST_BODY) {
informWriterError(conn);
log.warn("Exception occured while sending the request");
} else if (state == ProtocolState.RESPONSE_HEAD || state ==
ProtocolState.RESPONSE_BODY) {
informReaderError(conn);
log.warn("Exception occured while reading the response");
} else if (state == ProtocolState.REQUEST_DONE) {
informWriterError(conn);
log.warn("Exception occured while before reading the response");
}
if (ex instanceof IOException) {
logIOException(conn, (IOException) ex);
if (requestMsgCtx != null) {
targetErrorHandler.handleError(requestMsgCtx,
ErrorCodes.SND_IO_ERROR,
"Error in Sender",
ex,
state);
}
TargetContext.updateState(conn, ProtocolState.CLOSING);
} else if (ex instanceof HttpException) {
String message = getErrorMessage("HTTP protocol violation : " +
ex.getMessage(), conn);
log.error(message, ex);
if (requestMsgCtx != null) {
targetErrorHandler.handleError(requestMsgCtx,
ErrorCodes.PROTOCOL_VIOLATION,
"Error in Sender",
null,
state);
}
TargetContext.updateState(conn, ProtocolState.CLOSED);
} else {
if(null != ex && null != ex.getMessage()) {
log.error("Unexpected error: " + ex.getMessage(), ex);
} else {
log.error("Unexpected error.");
}
TargetContext.updateState(conn, ProtocolState.CLOSED);
}
targetConfiguration.getConnections().shutdownConnection(conn, true);
}
On Tue, May 17, 2016 at 3:03 PM, 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?
>
>
I do have doubt whether this would actually fullfill what we need, this
might specifically coupled at axis2 level, but IMO we should focus on
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
>
>
--
Dushan Abeyruwan | Technical Lead
PMC Member Apache Synpase
WSO2 Inc. http://wso2.com/
Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>*
LinkedIn:*https://www.linkedin.com/in/dushanabeyruwan
<https://www.linkedin.com/in/dushanabeyruwan>*
Mobile:(001)408-791-9312
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
