[
https://issues.apache.org/jira/browse/HTTPCORE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612676#action_12612676
]
Patrick Moore commented on HTTPCORE-165:
----------------------------------------
Changing BaseIOReactor:
protected void validate(final Set<SelectionKey> keys) {
long currentTime = System.currentTimeMillis();
if( (currentTime - this.lastTimeoutCheck) >= this.timeoutCheckInterval)
{
this.lastTimeoutCheck = currentTime;
if (keys != null) {
for (Iterator<SelectionKey> it = keys.iterator();
it.hasNext();) {
SelectionKey key = it.next();
try {
timeoutCheck(key, currentTime);
} catch(CancelledKeyException cancelledKeyException) {
it.remove();
}
}
}
}
protected void sessionClosed(final IOSession session) {
try {
this.eventDispatch.disconnected(session);
} catch (RuntimeException ex) {
try {
handleRuntimeException(ex);
} catch (CancelledKeyException cancelledKeyException) {
// nothing to do here.
}
}
}
--------------------------------------------------------------------------
IOReactorExceptionHandler:
/**
* This method is expected to examine the runtime exception passed as a
parameter
* and decide whether it is safe to continue execution of the I/O reactor
*
* @param ex potentially recoverable runtime exception
* @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} <strike>and
terminate</strike>
* For CancelledKeyException, true should be returned. All other exceptions
may terminate the IOReactor.
*/
boolean handle(RuntimeException ex);
------------------------------------------------------------------
I would suggest adding:
boolean handleTerminatingThrowable(Throwable throwable)
This way you can cleanly separate a decision about terminating the IOReactor
from if the exception should be rethrown. This method would be called if the
IOReactor thinks it should shutdown
Also the IOReactor just quietly shutsdown with out saying why,..
> 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
>
> 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]
