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: [email protected] For additional commands, e-mail: [email protected]
