hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: I/O dispatch worker terminated abnormally
Date Tue, 09 Aug 2011 14:00:05 GMT
On Mon, 2011-08-08 at 20:11 -0400, James Leigh wrote:
> On Mon, 2011-08-08 at 11:12 +0200, Oleg Kalnichevski wrote:
> > On Sun, 2011-08-07 at 19:56 -0400, James Leigh wrote:
> > > On Sun, 2011-08-07 at 23:34 +0200, Oleg Kalnichevski wrote:
> > > > On Sun, 2011-08-07 at 14:05 -0400, James Leigh wrote:
> > > > > Hi hc,
> > > > > 
> > > > > We have been developing with httpcore for almost 18 months and have
been
> > > > > really happy with it. However, as we push to have more public facing
Web
> > > > > server running httpcore we are concerned about abnormal client
> > > > > behaviour.
> > > > > 
> > > > > In the unusual event that an IOReactor throws an exception how can
we
> > > > > have the current connection closed without affecting the rest of
the
> > > > > server?
> > > > > 
> > > > > This can happen in an SSL connection, when the server does not have
the
> > > > > algorithm used by the client or the client does not follow the
> > > > > specification properly. It can also happen in unencrypted connections
> > > > > when something unexplained happens with the buffers, like the stack
> > > > > trace below.
> > > > > 
> > > > > I know that an IOReactorExceptionHandler can be used to distinguish
> > > > > between fatal and ignorable exceptions. However, fatal exceptions
> > > > > (re-thrown) seem to hang the server and ignored exceptions don't
closed
> > > > > the connection (so says the javadoc).
> > > > > 
> > > > > What is the best way to indicate that the TCP connection should be
> > > > > closed (not the IOReactor) on unexpected exceptions?
> > > > > 
> > > > 
> > > > Hi James
> > > > 
> > > > Usually protocol handlers are expected to handle all recoverable
> > > > exceptions including non-checked (runtime) ones. All events triggered
by
> > > > the I/O reactor and propagated to the protocol handler take place in a
> > > > context of a particular connection, so one can always choose to shut
> > > > down the connection if the exception can be recovered from. Those
> > > > exceptions that are not handled by the protocol handler or thrown by the
> > > > I/O reactor itself usually represent a programming error and therefore
> > > > considered non-recoverable (fatal). In those cases the best course of
> > > > action would be to let the I/O reactor shut down itself and be
> > > > restarted.
> > > > 
> > > 
> > > So, by letting the exception propagate, the i/o reactor is expected to
> > > be restarted. What class is responsible for restarting the i/o reactor?
> > 
> > Hi James
> > 
> > Usually decisions about problem severity as well as recovery logic tend
> > to be application specific. HttpCore has no built-in mechanism to
> > restart a failed I/O reactor. However application code can catch
> > IOReactorException and attempt to create a new instance in place of the
> > failed one. 
> > 
> > 
> > > I will run some more tests late next week and try and follow up with a
> > > reproducible scenario to demonstrate a non-checked exception that is not
> > > a programming error.
> > > 
> > 
> > Sure. I might well have missed a legitimate case where a runtime
> > exception represents a recoverable exception. I'll happily make amends.
> 
> Hi Oleg,
> 
> I haven't yet tried to restart i/o reactors (I'll let you know if I run
> into trouble with it later).

Consider catching runtime exceptions at the I/O dispatch level as I
suggested previously. That will take care of the immediate problem and
will ensure the I/O reactor remains operational even if something craps
out at the individual I/O session level.


>  However, below is a stack trace of a
> runtime exception. What concerns me is that a client can shutdown an i/o
> reactor remotely. An exception like this should be handled by the server
> (even if it just closes the session and continues).
>
> The server is running httpcore 4.1.3.
> OpenJDK Runtime Environment (IcedTea6 1.8.7) (6b18-1.8.7-2~squeeze1)
> OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
> 
> The client is a Black Berry PlayBook 1.0.7 browser attempting to open an
> SSL connection to the server.
> 
> Thanks,
> James
> 
> org.apache.http.nio.reactor.IOReactorException: I/O dispatch worker terminated abnormally
>         at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:321)
>         at org.openrdf.http.object.HTTPObjectServer$5.run(HTTPObjectServer.java:410)
>         at java.lang.Thread.run(Thread.java:636)
> Caused by: java.lang.RuntimeException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
>         at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1029)
>         at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:503)
>         at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:751)
>         at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:719)
>         at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)


Someone at Sun/Oracle had a bright idea to rethrow PKCS11Exception as
plain RuntimeException. Are they crazy?

Please raise a JIRA for HttpCore. We'll need to make sure that
SSIOSession shuts itself gracefully in case javax.net.ssl.SSLEngine does
something stupid like the exception above.

Oleg


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


Mime
View raw message