hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Moore (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCORE-165) Poor handling of CancelledKeyException with custom IOReactorExceptionHandler
Date Fri, 11 Jul 2008 19:58:31 GMT

    [ https://issues.apache.org/jira/browse/HTTPCORE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612976#action_12612976

Patrick Moore commented on HTTPCORE-165:

Hi Oleg --

Yeah. It looks like the patch would handle the big issues w.r.t. CanceledKeyException. I agree
that the IOReactorExceptionHandler probably should not see this kind of exception. Also the
question of InterruptedIOException also exists.

Still am thinking that that the IOReactorExceptionHandler will want to deal with the question
of exception propgation as a separate decision from terminating the IOReactor. Making the
2 equivalent works for the current implementation, but may not work for a custom IOReactor
implementation or the future version of BaseIOReactor. 

Right now -- the IOReactorExceptionHandler returns true if it wants the exception rethrown
with the expectation that this will result in the IOReactor terminating. But how do we handle
the case where the exception should be rethrown WITHOUT the expectation that the IOReactor
would terminate?

This would happen if we provide our own custom IOReactor. The custom reactor may handle certain
exceptions in a way that does not result in termination. 

For example, the custom reactor gets an IOException because the remote server dropped the
connection. The custom IOReactor notifies the IOReactorExceptionHandler. The IOReactorExceptionHandler
logs the issue and indicates "rethrow". the custom IOReactor does its recovery and retries.
Another error occurs. This time the IOReactorEH wraps exception and throws?, (returns?) the
new exception to be thrown. This new exception is not caught until the outer loop. At this
point,  the custom IOReactor calls:

 IOReactorStatus IOReactorEH.handleTerminatingThrowable(Throwable throwable) ;

The IOReactorEH would return the new IOReactorStatus. If the IOReactorStatus returned is RESTART
then the IOReactor would reinitialize and resume running. So conceptually the IOReactor has
"rebooted" itself.

This is critical in a server environment where modules will fail and need to be restarted
without requiring that the entire application be restarted. Enabling this mini-reboot functionality
is extremely useful in maintaining uptime.


* the IOReactorEH also needs to know what is the operation being attempted that caused the
exception. For example, if the IOReactor is doing a shutdown then the IOReactorExceptionHandler
may chose to ignore all exceptions. This should also include things like the connection url,
and other meaningful data. 
* the IOReactorEH should be passed the instance of the IOReactor to better support singleton

1. existing "handle" methods should really return the exception to be thrown to allow for
Exception wrapping.
  a. IOReactor should notify what operation was being attempted that caused the problem so
IOReactorEH could do more intelligent logging and handling.
  b. IOReactor should pass 'this' to the IOReactorEH so the IOReactorEH can be a stateless
2. separating the concept of propagate exception from terminating IOReactor.
3. enable IOReactorEH to trigger a restart of the IOReactor.



> Poor handling of CancelledKeyException with custom IOReactorExceptionHandler 
> -----------------------------------------------------------------------------
>                 Key: HTTPCORE-165
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-165
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore NIO
>    Affects Versions: 4.0-beta2
>            Reporter: Patrick Moore
>         Attachments: cancelledkey.patch
> IOReactorExceptionHandler documentation for handle(RuntimeException ex) is misleading.
Specifically the documentation says :
>      @return <code>true</code> if it is safe to ignore the exception 
>      and continue execution of the I/O reactor; <code>false</code> if the
>      I/O reactor must throw {@link RuntimeException} and terminate 
> However, a CancelledKeyException should be rethrown because the BaseIOReactor and the
AbstractIOReactor expect and handle CancelledKeyException correctly.
> BUT -- NOT always.
> Looking at the call stack for where IOReactorExceptionHandler.handle(RuntimeException)
is called reveals some problems.
> If a custom IOReactorExceptionHandler was to return false (indicating that the CanceledKeyException
was to be rethrown or to do the rethrow itself) WOULD result in the IOReactor being shutdown:
>   BaseIOReactor.sessionClosed(IOSession)
>   BaseIOReactor.timeoutCheck(SelectionKey, long)

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message