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 Mon, 08 Aug 2011 09:12:00 GMT
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message