[
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.
Continuing....
* 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 IOReactorEH.
Summary:
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 singleton.
2. separating the concept of propagate exception from terminating IOReactor.
3. enable IOReactorEH to trigger a restart of the IOReactor.
----------------------
Pat
> 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
