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?
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]
