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.
Another possibility to deal with runtime exceptions might be catching
them at the I/O dispatch level:
public class MyIODispatch extends DefaultServerIOEventDispatch {
public MyIODispatch(
NHttpServiceHandler handler, HttpParams params) {
super(handler, params);
}
@Override
public void inputReady(IOSession session) {
try {
super.inputReady(session);
} catch (RuntimeException ex) {
session.shutdown();
throw ex;
}
}
}
This should make it possible to recover from runtime exceptions thrown
anywhere in the HTTP protocol handling code.
Hope this makes some sense.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
