hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: HttpCore NIOSSL fatal exception
Date Wed, 28 Nov 2007 11:35:51 GMT

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: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> 
> 


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


Mime
View raw message