hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Leigh <james-nos...@leighnet.ca>
Subject Re: I/O dispatch worker terminated abnormally
Date Tue, 09 Aug 2011 00:11:17 GMT
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). 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)
        at org.apache.http.impl.nio.reactor.SSLIOSession.doHandshake(SSLIOSession.java:163)
        at org.apache.http.impl.nio.reactor.SSLIOSession.isAppInputReady(SSLIOSession.java:265)
        at org.apache.http.impl.nio.SSLServerIOEventDispatch.inputReady(SSLServerIOEventDispatch.java:229)
        at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:158)
        at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:340)
        at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:318)
        at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:278)
        at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104)
        at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:542)
        ... 1 more
Caused by: java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
        at sun.security.pkcs11.P11KeyPairGenerator.generateKeyPair(P11KeyPairGenerator.java:323)
        at java.security.KeyPairGenerator$Delegate.generateKeyPair(KeyPairGenerator.java:673)
        at sun.security.ssl.ECDHCrypt.<init>(ECDHCrypt.java:63)
        at sun.security.ssl.ServerHandshaker.setupEphemeralECDHKeys(ServerHandshaker.java:991)
        at sun.security.ssl.ServerHandshaker.trySetCipherSuite(ServerHandshaker.java:872)
        at sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:801)
        at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:576)
        at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:170)
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:610)
        at sun.security.ssl.Handshaker$1.run(Handshaker.java:550)
        at sun.security.ssl.Handshaker$1.run(Handshaker.java:548)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:969)
        at org.apache.http.impl.nio.reactor.SSLIOSession.doHandshake(SSLIOSession.java:171)
        ... 9 more
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
        at sun.security.pkcs11.wrapper.PKCS11.C_GenerateKeyPair(Native Method)
        at sun.security.pkcs11.P11KeyPairGenerator.generateKeyPair(P11KeyPairGenerator.java:314)
        ... 22 more



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


Mime
View raw message