You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by James Leigh <ja...@leighnet.ca> on 2011/08/07 20:05:59 UTC
I/O dispatch worker terminated abnormally
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?
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:326)
at org.openrdf.http.object.HTTPObjectServer$4.run(HTTPObjectServer.java:386)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:249)
at org.apache.http.impl.nio.codecs.LengthDelimitedDecoder.read(LengthDelimitedDecoder.java:95)
at org.openrdf.http.object.util.ReadableContentListener.contentAvailable(ReadableContentListener.java:140)
at org.apache.http.nio.entity.ConsumingNHttpEntityTemplate.consumeContent(ConsumingNHttpEntityTemplate.java:94)
at org.apache.http.nio.protocol.AsyncNHttpServiceHandler.inputReady(AsyncNHttpServiceHandler.java:317)
at org.apache.http.impl.nio.DefaultNHttpServerConnection.consumeInput(DefaultNHttpServerConnection.java:179)
at org.apache.http.impl.nio.DefaultServerIOEventDispatch.inputReady(DefaultServerIOEventDispatch.java:145)
at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:153)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:314)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:294)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:256)
at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:96)
at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:556)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: I/O dispatch worker terminated abnormally
Posted by James Leigh <ja...@leighnet.ca>.
On Tue, 2011-08-09 at 16:00 +0200, Oleg Kalnichevski wrote:
> On Mon, 2011-08-08 at 20:11 -0400, James Leigh wrote:
> > 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
>
Crazy I know, but this is why I want runtime exceptions caught.
I created https://issues.apache.org/jira/browse/HTTPCORE-268
Thanks,
James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: I/O dispatch worker terminated abnormally
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
Re: I/O dispatch worker terminated abnormally
Posted by James Leigh <ja...@leighnet.ca>.
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
Re: I/O dispatch worker terminated abnormally
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
Re: I/O dispatch worker terminated abnormally
Posted by James Leigh <ja...@leighnet.ca>.
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?
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.
>
> > Caused by: java.lang.IllegalArgumentException
> > at java.nio.Buffer.limit(Buffer.java:249)
> > at org.apache.http.impl.nio.codecs.LengthDelimitedDecoder.read(LengthDelimitedDecoder.java:95)
>
> The IllegalArgumentException thrown inside LengthDelimitedDecoder
> appears to be a bug in HttpCore, which need to be fixed. I do not think
> there is a reasonable way of recovering from such exceptions.
>
> Is there a way to reproduce it? Are you using the latest version of
> HttpCore?
>
> Cheers
>
> Oleg
>
No, the exception was not with the latest version and I think this bug
has since been fixed in later versions of httpcore.
James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: I/O dispatch worker terminated abnormally
Posted by Oleg Kalnichevski <ol...@apache.org>.
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.
> Caused by: java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:249)
> at org.apache.http.impl.nio.codecs.LengthDelimitedDecoder.read(LengthDelimitedDecoder.java:95)
The IllegalArgumentException thrown inside LengthDelimitedDecoder
appears to be a bug in HttpCore, which need to be fixed. I do not think
there is a reasonable way of recovering from such exceptions.
Is there a way to reproduce it? Are you using the latest version of
HttpCore?
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org