On Wed, 2007-11-28 at 04:37 +0100, Roland Weber wrote:
> Hi Jake,
>
> you'll get better info from the NIO folks, but here
> are the points I can answer...
>
> > First off, I'm sorry if this is the wrong place,
>
> It's not. We kept the name of the user list because
> that's the best-known deliverable we have.
>
> > Exception in thread "I/O reactor worker thread 1"
> > java.lang.IllegalStateException: Internal error
> > at com.sun.net.ssl.internal.ssl.SSLEngineImpl.initHandshaker(Unknown
> > Source)
>
> Whop - a RuntimeException out of SUN's SSL implementation.
> Not what you would normally expect.
>
> > When I look at the SVN source, I see that the code only catches
> > IOException, but doesn't handle Throwable
>
> works as designed
>
> > Why was an IllegalStateException thrown?
>
> Check the SUN forums. It's their code that hit an internal error
> of unspecified nature.
>
> > Do these "reactor worker threads" have a limited shelf life,
> > and have to be "exercised" every once it a while?
>
> As with all worker threads: if they fail to work, throw them away
> and replace them. But you may want to know why the worker failed.
> Because if there's something wrong in the environment, the newly
> started ones will also fail.
>
> > Why isn't Throwable caught and handled in SSLServerIOEventDispatch?
>
> Because a general Throwable is not an IO event. It's an IO event
> if the other side closes the connection, or if there is a timeout
> on network communication. But an internal error somewhere? That
> can mean anything from a parse error because somebody sent plain
> HTTP on an SSL port to an OutOfMemory or ClassNotFound condition
> that really crashes your application.
>
> > Wouldn't it make sense to convert it to a IOException so the application
> > can be notified that there was a problem ("this.handler.exception(new
> > IOException("Unknown exception", throwable));sslSession.shutdown();")?
>
> See above... who are we to decide whether that makes sense?
> Maybe it's a problem with the data being received, maybe it's
> a problem with the setup of the SSL keys and certificates.
> One can reasonably be considered an IO problem, the other cannot.
> Runtime exceptions should be dealt with by application code
> on a case-by-case basis. General throwables should generally
> be dealt with by stopping the application.
> The framework will not make such decisions for you. If you
> feel that these exceptions should be mapped, plug in your
> code for exception mapping. If there is no suitable plug-in
> point, ask for it here or on our dev list.
>
> > If for some reason it just isn't considered acceptable to convert a
> > RuntimeException to an IOException, how do I detect this situation
> > and recover from it?
>
Jake,
Generally it is a pretty bad idea to do anything with _generic_
RuntimeException as semantically they are meant to represent
non-recoverable exceptions.
As of HttpCore 4.0-alpha6 you can register a custom
IOReactorExceptionHandler to inject application specific exception
handling logic for I/O and runtime exceptions that are deemed
non-fatal:
http://jakarta.apache.org/httpcomponents/httpcomponents-core/httpcore-nio/xref/org/apache/http/nio/reactor/IOReactorExceptionHandler.html
Hope this helps
Oleg
> The guys who know the NIO code will answer those questions.
>
> cheers,
> Roland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
