You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Jake C <bu...@hotmail.com> on 2007/11/27 22:04:30 UTC
HttpCore NIOSSL fatal exception
First off, I'm sorry if this is the wrong place, but there is no httpcomponents-user list, and I am not using HttpClient.
I based my server on the "Basic non-blocking HTTPS server" example at http://jakarta.apache.org/httpcomponents/httpcomponents-core/examples.html, and I'm using 4.0-alpha4 running on JDK 6.
All I ever get hit with is a simple URL with a few parameters on it, and I just respond with SC_OK. We are currently in development, so my server usually just gets hit from a couple times a day to maybe 10 times.
It usually runs fine, but the other day the following errors came out on System.err:
Exception in thread "I/O reactor worker thread 1" java.lang.IllegalStateException: Internal error
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.initHandshaker(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(Unknown Source)
at javax.net.ssl.SSLEngine.unwrap(Unknown Source)
at org.apache.http.impl.nio.reactor.SSLIOSession.decryptData(SSLIOSession.java:239)
at org.apache.http.impl.nio.reactor.SSLIOSession.isAppInputReady(SSLIOSession.java:258)
at org.apache.http.impl.nio.reactor.SSLServerIOEventDispatch.inputReady(SSLServerIOEventDispatch.java:122)
at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:68)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:160)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:145)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:127)
at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:153)
at java.lang.Thread.run(Unknown Source)
Exception in thread "I/O reactor worker thread 2" java.lang.IllegalStateException: Internal error
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.initHandshaker(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(Unknown Source)
at javax.net.ssl.SSLEngine.unwrap(Unknown Source)
at org.apache.http.impl.nio.reactor.SSLIOSession.doHandshake(SSLIOSession.java:155)
at org.apache.http.impl.nio.reactor.SSLIOSession.isAppInputReady(SSLIOSession.java:257)
at org.apache.http.impl.nio.reactor.SSLServerIOEventDispatch.inputReady(SSLServerIOEventDispatch.java:122)
at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:68)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:160)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:145)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:127)
at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:153)
at java.lang.Thread.run(Unknown Source)
This did NOT come through the EventListener that was set in the handler, so my code does not receive any warning that there was a problem, but from that point on, there were no threads listening on the SSL port.
This, of course, is bad. :-) My app has basically crashed and I know nothing about it except that something got printed to System.err. Even that doesn't let me know that it was a fatal error that crashed the worker threads.
When I look at the SVN source, I see that the code only catches IOException, but doesn't handle Throwable, which is why I didn't get notified of the Exception, since IllegalStateException is a RuntimeException.
So, of course, I have some questions.
Why was an IllegalStateException thrown? Do these "reactor worker threads" have a limited shelf life, and have to be "exercised" every once it a while? It is possible my server had been idle for a couple days at that point.
Why isn't Throwable caught and handled in SSLServerIOEventDispatch? Wouldn't it make sense to convert it to a IOException so the application can be notified that there was a problem ("this.handler.exception(new IOException("Unknown exception", throwable));sslSession.shutdown();")?
If for some reason it just isn't considered acceptable to convert a RuntimeException to an IOException, how do I detect this situation and recover from it?
If it IS acceptable to do that, and I get notified via EventListener.fatalIOException(), how do I recover from the situation? Can I detect that a worker thread has died, and if so, can I restart it, or start a new one? If so, how?
_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: HttpCore NIOSSL fatal exception
Posted by Roland Weber <os...@dubioso.net>.
I got up too early...
Roland Weber wrote:
> It's not. We kept the name of the user list because
> that's the best-known deliverable we have.
> [...]
> ask for it here or on our dev list.
Here is our dev list :-)
The user list would also have been ok.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
RE: HttpCore NIOSSL fatal exception
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2007-12-03 at 20:24 +0000, Jake C wrote:
> Thanks for the reply!
>
> Sorry for the long delay in reply, I suddenly got really busy last week... :-)
>
> > Subject: Re: HttpCore NIOSSL fatal exception
> > From: olegk@apache.org
> > To: httpcomponents-dev@jakarta.apache.org
> > Date: Wed, 28 Nov 2007 12:35:51 +0100
> >
> >
> > On Wed, 2007-11-28 at 04:37 +0100, Roland Weber wrote:
> >>
> >>> Do these "reactor worker threads" have a limited shelf life,
> >>> and have to be "exercised" every once it a while?
> >>
> >> As with all worker threads: if they fail to work, throw them away
> >> and replace them. But you may want to know why the worker failed.
> >> Because if there's something wrong in the environment, the newly
> >> started ones will also fail.
>
> If this does end up being a recoverable error, how do I go about replacing them? They were created in the constructor for DefaultListeningIOReactor. Do I need to call shutdown on the ioRector instance and create a new one?
>
> I definitely want to know why. I will be following up with the NIO list. I hope I don't have to go to Sun... :-/
>
Jake,
You can prevent the worker threads from terminating by "handling"
exceptions using IOReactorExceptionHandler. In case the handler is not
provided or the handling method returns false, the worker thread will
store the exception in a local variable and terminate. The I/O reactor
in its turn will detect the fatal failure condition, re-throw the
original exception and gracefully shut down itself along with the
remaining worker threads. One can still recover from this condition by
catching the exception and restating the I/O reactor
Hope this helps
Oleg
> > Generally it is a pretty bad idea to do anything with _generic_
> > RuntimeException as semantically they are meant to represent
> > non-recoverable exceptions.
> >
> > As of HttpCore 4.0-alpha6 you can register a custom
> > IOReactorExceptionHandler to inject application specific exception
> > handling logic for I/O and runtime exceptions that are deemed
> > non-fatal:
> >
> > http://jakarta.apache.org/httpcomponents/httpcomponents-core/httpcore-nio/xref/org/apache/http/nio/reactor/IOReactorExceptionHandler.html
> >
> > Hope this helps
> >
> > Oleg
>
> This may end up being a fatal error, and the "handling" may be to restart the app, or even a reboot. However, without knowing that there was even a problem, I couldn't do even that until I get a phone call that notifications are not going through. That would remove a couple 9's from my uptime. :-) I'll check out the new IOReactorExceptionHandler. Knowing there was an error is definitely the first step.
> _________________________________________________________________
> Share life as it happens with the new Windows Live.Download today it's FREE!
> http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: HttpCore NIOSSL fatal exception
Posted by Tatu Saloranta <co...@yahoo.com>.
--- Sam Berlin <sb...@gmail.com> wrote:
...
> important to keep in mind). Otherwise 50
> connections require 100
> threads (one for writing, one for reading, for each
> connection).
> While this may not be a problem on enterprise-level
> machines, it is a
> big deal for consumer-level machines.
It is often a problem even with enterprise-level
machines (or at least machines used by big
enterprises... :-)), I think.
JVMs do not scale particularly well with high number
of threads, at least on platforms I'm familiar with.
-+ Tatu +-
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: HttpCore NIOSSL fatal exception
Posted by Sam Berlin <sb...@gmail.com>.
Hi Oleg,
Another very good reason to switch to NIO is if your application is if
you are handling many different connections simultaneous. This is
especially true if your application requires reading & writing to
happen independent of each other (not the case with HTTP, but it's
important to keep in mind). Otherwise 50 connections require 100
threads (one for writing, one for reading, for each connection).
While this may not be a problem on enterprise-level machines, it is a
big deal for consumer-level machines.
Sam
On 12/5/07, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> On Tue, 2007-12-04 at 00:31 +0000, Jake C wrote:
> > Wow, that is kind of scary!
> >
> > We are in control of our environment. However, we are actually fairly low volume. All the data we need we receive in the URL itself, and we only ever reply with OK. Is there a way to use just the regular HttpCore to set up a server listening on a SSL port, without using NIO?
>
> Absolutely.
>
> If you application does not have to deal with thousands of simultaneous
> connections with high request/response latency, NIO provides little, if
> any, benefit compared to the classic I/O. One should seriously consider
> going away from the one thread per connection model only if worker
> threads spend most of their time blocked in I/O doing nothing.
>
> Oleg
>
> >
> > > Date: Mon, 3 Dec 2007 15:39:45 -0500
> > > From: sberlin@gmail.com
> > > To: httpcomponents-dev@jakarta.apache.org
> > > Subject: Re: HttpCore NIOSSL fatal exception
> > >
> > > We've found that as we began using NIO (and SSL in NIO), we had to
> > > deal with and workaround a lot of internal Sun bugs. Most
> > > NIO-specific ones were hammered out in later releases of Java 1.5, but
> > > given that SSLEngine was just introduced in Java5, it'll probably take
> > > till later releases of Java6 or Java7 to really work out all the
> > > kinks. We actually had to run a small test on startup of the
> > > application and disable SSL on environments that failed to load it
> > > (for whatever reason) (see:
> > > https://www.limewire.org/fisheye/browse/~raw,r=1.2/limecvs/components/nio/src/main/java/org/limewire/nio/ssl/SSLEngineTest.java
> > > ). Some of the errors we saw made absolutely no sense, but were
> > > internal to Java and we had no way of working around them. If you're
> > > in control of the environment, you should have a little more
> > > capability to fix these errors.
> > >
> > > Sam
> > >
> > > On 12/3/07, Jake C <bu...@hotmail.com> wrote:
> > > >
> > > > Thanks for the reply!
> > > >
> > > > Sorry for the long delay in reply, I suddenly got really busy last week... :-)
> > > >
> > > > > Subject: Re: HttpCore NIOSSL fatal exception
> > > > > From: olegk@apache.org
> > > > > To: httpcomponents-dev@jakarta.apache.org
> > > > > Date: Wed, 28 Nov 2007 12:35:51 +0100
> > > > >
> > > > >
> > > > > On Wed, 2007-11-28 at 04:37 +0100, Roland Weber wrote:
> > > > >>
> > > > >>> Do these "reactor worker threads" have a limited shelf life,
> > > > >>> and have to be "exercised" every once it a while?
> > > > >>
> > > > >> As with all worker threads: if they fail to work, throw them away
> > > > >> and replace them. But you may want to know why the worker failed.
> > > > >> Because if there's something wrong in the environment, the newly
> > > > >> started ones will also fail.
> > > >
> > > > If this does end up being a recoverable error, how do I go about replacing them? They were created in the constructor for DefaultListeningIOReactor. Do I need to call shutdown on the ioRector instance and create a new one?
> > > >
> > > > I definitely want to know why. I will be following up with the NIO list. I hope I don't have to go to Sun... :-/
> > > >
> > > > > Generally it is a pretty bad idea to do anything with _generic_
> > > > > RuntimeException as semantically they are meant to represent
> > > > > non-recoverable exceptions.
> > > > >
> > > > > As of HttpCore 4.0-alpha6 you can register a custom
> > > > > IOReactorExceptionHandler to inject application specific exception
> > > > > handling logic for I/O and runtime exceptions that are deemed
> > > > > non-fatal:
> > > > >
> > > > > http://jakarta.apache.org/httpcomponents/httpcomponents-core/httpcore-nio/xref/org/apache/http/nio/reactor/IOReactorExceptionHandler.html
> > > > >
> > > > > Hope this helps
> > > > >
> > > > > Oleg
> > > >
> > > > This may end up being a fatal error, and the "handling" may be to restart the app, or even a reboot. However, without knowing that there was even a problem, I couldn't do even that until I get a phone call that notifications are not going through. That would remove a couple 9's from my uptime. :-) I'll check out the new IOReactorExceptionHandler. Knowing there was an error is definitely the first step.
> > > > _________________________________________________________________
> > > > Share life as it happens with the new Windows Live.Download today it's FREE!
> > > > http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> > >
> >
> > _________________________________________________________________
> > Share life as it happens with the new Windows Live.Download today it's FREE!
> > http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
RE: HttpCore NIOSSL fatal exception
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2007-12-04 at 00:31 +0000, Jake C wrote:
> Wow, that is kind of scary!
>
> We are in control of our environment. However, we are actually fairly low volume. All the data we need we receive in the URL itself, and we only ever reply with OK. Is there a way to use just the regular HttpCore to set up a server listening on a SSL port, without using NIO?
Absolutely.
If you application does not have to deal with thousands of simultaneous
connections with high request/response latency, NIO provides little, if
any, benefit compared to the classic I/O. One should seriously consider
going away from the one thread per connection model only if worker
threads spend most of their time blocked in I/O doing nothing.
Oleg
>
> > Date: Mon, 3 Dec 2007 15:39:45 -0500
> > From: sberlin@gmail.com
> > To: httpcomponents-dev@jakarta.apache.org
> > Subject: Re: HttpCore NIOSSL fatal exception
> >
> > We've found that as we began using NIO (and SSL in NIO), we had to
> > deal with and workaround a lot of internal Sun bugs. Most
> > NIO-specific ones were hammered out in later releases of Java 1.5, but
> > given that SSLEngine was just introduced in Java5, it'll probably take
> > till later releases of Java6 or Java7 to really work out all the
> > kinks. We actually had to run a small test on startup of the
> > application and disable SSL on environments that failed to load it
> > (for whatever reason) (see:
> > https://www.limewire.org/fisheye/browse/~raw,r=1.2/limecvs/components/nio/src/main/java/org/limewire/nio/ssl/SSLEngineTest.java
> > ). Some of the errors we saw made absolutely no sense, but were
> > internal to Java and we had no way of working around them. If you're
> > in control of the environment, you should have a little more
> > capability to fix these errors.
> >
> > Sam
> >
> > On 12/3/07, Jake C <bu...@hotmail.com> wrote:
> > >
> > > Thanks for the reply!
> > >
> > > Sorry for the long delay in reply, I suddenly got really busy last week... :-)
> > >
> > > > Subject: Re: HttpCore NIOSSL fatal exception
> > > > From: olegk@apache.org
> > > > To: httpcomponents-dev@jakarta.apache.org
> > > > Date: Wed, 28 Nov 2007 12:35:51 +0100
> > > >
> > > >
> > > > On Wed, 2007-11-28 at 04:37 +0100, Roland Weber wrote:
> > > >>
> > > >>> Do these "reactor worker threads" have a limited shelf life,
> > > >>> and have to be "exercised" every once it a while?
> > > >>
> > > >> As with all worker threads: if they fail to work, throw them away
> > > >> and replace them. But you may want to know why the worker failed.
> > > >> Because if there's something wrong in the environment, the newly
> > > >> started ones will also fail.
> > >
> > > If this does end up being a recoverable error, how do I go about replacing them? They were created in the constructor for DefaultListeningIOReactor. Do I need to call shutdown on the ioRector instance and create a new one?
> > >
> > > I definitely want to know why. I will be following up with the NIO list. I hope I don't have to go to Sun... :-/
> > >
> > > > Generally it is a pretty bad idea to do anything with _generic_
> > > > RuntimeException as semantically they are meant to represent
> > > > non-recoverable exceptions.
> > > >
> > > > As of HttpCore 4.0-alpha6 you can register a custom
> > > > IOReactorExceptionHandler to inject application specific exception
> > > > handling logic for I/O and runtime exceptions that are deemed
> > > > non-fatal:
> > > >
> > > > http://jakarta.apache.org/httpcomponents/httpcomponents-core/httpcore-nio/xref/org/apache/http/nio/reactor/IOReactorExceptionHandler.html
> > > >
> > > > Hope this helps
> > > >
> > > > Oleg
> > >
> > > This may end up being a fatal error, and the "handling" may be to restart the app, or even a reboot. However, without knowing that there was even a problem, I couldn't do even that until I get a phone call that notifications are not going through. That would remove a couple 9's from my uptime. :-) I'll check out the new IOReactorExceptionHandler. Knowing there was an error is definitely the first step.
> > > _________________________________________________________________
> > > Share life as it happens with the new Windows Live.Download today it's FREE!
> > > http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> >
>
> _________________________________________________________________
> Share life as it happens with the new Windows Live.Download today it's FREE!
> http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
RE: HttpCore NIOSSL fatal exception
Posted by Jake C <bu...@hotmail.com>.
Wow, that is kind of scary!
We are in control of our environment. However, we are actually fairly low volume. All the data we need we receive in the URL itself, and we only ever reply with OK. Is there a way to use just the regular HttpCore to set up a server listening on a SSL port, without using NIO?
> Date: Mon, 3 Dec 2007 15:39:45 -0500
> From: sberlin@gmail.com
> To: httpcomponents-dev@jakarta.apache.org
> Subject: Re: HttpCore NIOSSL fatal exception
>
> We've found that as we began using NIO (and SSL in NIO), we had to
> deal with and workaround a lot of internal Sun bugs. Most
> NIO-specific ones were hammered out in later releases of Java 1.5, but
> given that SSLEngine was just introduced in Java5, it'll probably take
> till later releases of Java6 or Java7 to really work out all the
> kinks. We actually had to run a small test on startup of the
> application and disable SSL on environments that failed to load it
> (for whatever reason) (see:
> https://www.limewire.org/fisheye/browse/~raw,r=1.2/limecvs/components/nio/src/main/java/org/limewire/nio/ssl/SSLEngineTest.java
> ). Some of the errors we saw made absolutely no sense, but were
> internal to Java and we had no way of working around them. If you're
> in control of the environment, you should have a little more
> capability to fix these errors.
>
> Sam
>
> On 12/3/07, Jake C <bu...@hotmail.com> wrote:
> >
> > Thanks for the reply!
> >
> > Sorry for the long delay in reply, I suddenly got really busy last week... :-)
> >
> > > Subject: Re: HttpCore NIOSSL fatal exception
> > > From: olegk@apache.org
> > > To: httpcomponents-dev@jakarta.apache.org
> > > Date: Wed, 28 Nov 2007 12:35:51 +0100
> > >
> > >
> > > On Wed, 2007-11-28 at 04:37 +0100, Roland Weber wrote:
> > >>
> > >>> Do these "reactor worker threads" have a limited shelf life,
> > >>> and have to be "exercised" every once it a while?
> > >>
> > >> As with all worker threads: if they fail to work, throw them away
> > >> and replace them. But you may want to know why the worker failed.
> > >> Because if there's something wrong in the environment, the newly
> > >> started ones will also fail.
> >
> > If this does end up being a recoverable error, how do I go about replacing them? They were created in the constructor for DefaultListeningIOReactor. Do I need to call shutdown on the ioRector instance and create a new one?
> >
> > I definitely want to know why. I will be following up with the NIO list. I hope I don't have to go to Sun... :-/
> >
> > > Generally it is a pretty bad idea to do anything with _generic_
> > > RuntimeException as semantically they are meant to represent
> > > non-recoverable exceptions.
> > >
> > > As of HttpCore 4.0-alpha6 you can register a custom
> > > IOReactorExceptionHandler to inject application specific exception
> > > handling logic for I/O and runtime exceptions that are deemed
> > > non-fatal:
> > >
> > > http://jakarta.apache.org/httpcomponents/httpcomponents-core/httpcore-nio/xref/org/apache/http/nio/reactor/IOReactorExceptionHandler.html
> > >
> > > Hope this helps
> > >
> > > Oleg
> >
> > This may end up being a fatal error, and the "handling" may be to restart the app, or even a reboot. However, without knowing that there was even a problem, I couldn't do even that until I get a phone call that notifications are not going through. That would remove a couple 9's from my uptime. :-) I'll check out the new IOReactorExceptionHandler. Knowing there was an error is definitely the first step.
> > _________________________________________________________________
> > Share life as it happens with the new Windows Live.Download today it's FREE!
> > http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
_________________________________________________________________
Share life as it happens with the new Windows Live.Download today it's FREE!
http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007
Re: HttpCore NIOSSL fatal exception
Posted by Sam Berlin <sb...@gmail.com>.
We've found that as we began using NIO (and SSL in NIO), we had to
deal with and workaround a lot of internal Sun bugs. Most
NIO-specific ones were hammered out in later releases of Java 1.5, but
given that SSLEngine was just introduced in Java5, it'll probably take
till later releases of Java6 or Java7 to really work out all the
kinks. We actually had to run a small test on startup of the
application and disable SSL on environments that failed to load it
(for whatever reason) (see:
https://www.limewire.org/fisheye/browse/~raw,r=1.2/limecvs/components/nio/src/main/java/org/limewire/nio/ssl/SSLEngineTest.java
). Some of the errors we saw made absolutely no sense, but were
internal to Java and we had no way of working around them. If you're
in control of the environment, you should have a little more
capability to fix these errors.
Sam
On 12/3/07, Jake C <bu...@hotmail.com> wrote:
>
> Thanks for the reply!
>
> Sorry for the long delay in reply, I suddenly got really busy last week... :-)
>
> > Subject: Re: HttpCore NIOSSL fatal exception
> > From: olegk@apache.org
> > To: httpcomponents-dev@jakarta.apache.org
> > Date: Wed, 28 Nov 2007 12:35:51 +0100
> >
> >
> > On Wed, 2007-11-28 at 04:37 +0100, Roland Weber wrote:
> >>
> >>> Do these "reactor worker threads" have a limited shelf life,
> >>> and have to be "exercised" every once it a while?
> >>
> >> As with all worker threads: if they fail to work, throw them away
> >> and replace them. But you may want to know why the worker failed.
> >> Because if there's something wrong in the environment, the newly
> >> started ones will also fail.
>
> If this does end up being a recoverable error, how do I go about replacing them? They were created in the constructor for DefaultListeningIOReactor. Do I need to call shutdown on the ioRector instance and create a new one?
>
> I definitely want to know why. I will be following up with the NIO list. I hope I don't have to go to Sun... :-/
>
> > Generally it is a pretty bad idea to do anything with _generic_
> > RuntimeException as semantically they are meant to represent
> > non-recoverable exceptions.
> >
> > As of HttpCore 4.0-alpha6 you can register a custom
> > IOReactorExceptionHandler to inject application specific exception
> > handling logic for I/O and runtime exceptions that are deemed
> > non-fatal:
> >
> > http://jakarta.apache.org/httpcomponents/httpcomponents-core/httpcore-nio/xref/org/apache/http/nio/reactor/IOReactorExceptionHandler.html
> >
> > Hope this helps
> >
> > Oleg
>
> This may end up being a fatal error, and the "handling" may be to restart the app, or even a reboot. However, without knowing that there was even a problem, I couldn't do even that until I get a phone call that notifications are not going through. That would remove a couple 9's from my uptime. :-) I'll check out the new IOReactorExceptionHandler. Knowing there was an error is definitely the first step.
> _________________________________________________________________
> Share life as it happens with the new Windows Live.Download today it's FREE!
> http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
RE: HttpCore NIOSSL fatal exception
Posted by Jake C <bu...@hotmail.com>.
Thanks for the reply!
Sorry for the long delay in reply, I suddenly got really busy last week... :-)
> Subject: Re: HttpCore NIOSSL fatal exception
> From: olegk@apache.org
> To: httpcomponents-dev@jakarta.apache.org
> Date: Wed, 28 Nov 2007 12:35:51 +0100
>
>
> On Wed, 2007-11-28 at 04:37 +0100, Roland Weber wrote:
>>
>>> Do these "reactor worker threads" have a limited shelf life,
>>> and have to be "exercised" every once it a while?
>>
>> As with all worker threads: if they fail to work, throw them away
>> and replace them. But you may want to know why the worker failed.
>> Because if there's something wrong in the environment, the newly
>> started ones will also fail.
If this does end up being a recoverable error, how do I go about replacing them? They were created in the constructor for DefaultListeningIOReactor. Do I need to call shutdown on the ioRector instance and create a new one?
I definitely want to know why. I will be following up with the NIO list. I hope I don't have to go to Sun... :-/
> Generally it is a pretty bad idea to do anything with _generic_
> RuntimeException as semantically they are meant to represent
> non-recoverable exceptions.
>
> As of HttpCore 4.0-alpha6 you can register a custom
> IOReactorExceptionHandler to inject application specific exception
> handling logic for I/O and runtime exceptions that are deemed
> non-fatal:
>
> http://jakarta.apache.org/httpcomponents/httpcomponents-core/httpcore-nio/xref/org/apache/http/nio/reactor/IOReactorExceptionHandler.html
>
> Hope this helps
>
> Oleg
This may end up being a fatal error, and the "handling" may be to restart the app, or even a reboot. However, without knowing that there was even a problem, I couldn't do even that until I get a phone call that notifications are not going through. That would remove a couple 9's from my uptime. :-) I'll check out the new IOReactorExceptionHandler. Knowing there was an error is definitely the first step.
_________________________________________________________________
Share life as it happens with the new Windows Live.Download today it's FREE!
http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: HttpCore NIOSSL fatal exception
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2007-11-28 at 04:37 +0100, Roland Weber wrote:
> Hi Jake,
>
> you'll get better info from the NIO folks, but here
> are the points I can answer...
>
> > First off, I'm sorry if this is the wrong place,
>
> It's not. We kept the name of the user list because
> that's the best-known deliverable we have.
>
> > Exception in thread "I/O reactor worker thread 1" java.lang.IllegalStateException: Internal error
> > at com.sun.net.ssl.internal.ssl.SSLEngineImpl.initHandshaker(Unknown Source)
>
> Whop - a RuntimeException out of SUN's SSL implementation.
> Not what you would normally expect.
>
> > When I look at the SVN source, I see that the code only catches
> > IOException, but doesn't handle Throwable
>
> works as designed
>
> > Why was an IllegalStateException thrown?
>
> Check the SUN forums. It's their code that hit an internal error
> of unspecified nature.
>
> > Do these "reactor worker threads" have a limited shelf life,
> > and have to be "exercised" every once it a while?
>
> As with all worker threads: if they fail to work, throw them away
> and replace them. But you may want to know why the worker failed.
> Because if there's something wrong in the environment, the newly
> started ones will also fail.
>
> > Why isn't Throwable caught and handled in SSLServerIOEventDispatch?
>
> Because a general Throwable is not an IO event. It's an IO event
> if the other side closes the connection, or if there is a timeout
> on network communication. But an internal error somewhere? That
> can mean anything from a parse error because somebody sent plain
> HTTP on an SSL port to an OutOfMemory or ClassNotFound condition
> that really crashes your application.
>
> > Wouldn't it make sense to convert it to a IOException so the application
> > can be notified that there was a problem ("this.handler.exception(new
> > IOException("Unknown exception", throwable));sslSession.shutdown();")?
>
> See above... who are we to decide whether that makes sense?
> Maybe it's a problem with the data being received, maybe it's
> a problem with the setup of the SSL keys and certificates.
> One can reasonably be considered an IO problem, the other cannot.
> Runtime exceptions should be dealt with by application code
> on a case-by-case basis. General throwables should generally
> be dealt with by stopping the application.
> The framework will not make such decisions for you. If you
> feel that these exceptions should be mapped, plug in your
> code for exception mapping. If there is no suitable plug-in
> point, ask for it here or on our dev list.
>
> > If for some reason it just isn't considered acceptable to convert a
> > RuntimeException to an IOException, how do I detect this situation
> > and recover from it?
>
Jake,
Generally it is a pretty bad idea to do anything with _generic_
RuntimeException as semantically they are meant to represent
non-recoverable exceptions.
As of HttpCore 4.0-alpha6 you can register a custom
IOReactorExceptionHandler to inject application specific exception
handling logic for I/O and runtime exceptions that are deemed
non-fatal:
http://jakarta.apache.org/httpcomponents/httpcomponents-core/httpcore-nio/xref/org/apache/http/nio/reactor/IOReactorExceptionHandler.html
Hope this helps
Oleg
> The guys who know the NIO code will answer those questions.
>
> cheers,
> Roland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: HttpCore NIOSSL fatal exception
Posted by Roland Weber <os...@dubioso.net>.
Hi Jake,
you'll get better info from the NIO folks, but here
are the points I can answer...
> First off, I'm sorry if this is the wrong place,
It's not. We kept the name of the user list because
that's the best-known deliverable we have.
> Exception in thread "I/O reactor worker thread 1" java.lang.IllegalStateException: Internal error
> at com.sun.net.ssl.internal.ssl.SSLEngineImpl.initHandshaker(Unknown Source)
Whop - a RuntimeException out of SUN's SSL implementation.
Not what you would normally expect.
> When I look at the SVN source, I see that the code only catches
> IOException, but doesn't handle Throwable
works as designed
> Why was an IllegalStateException thrown?
Check the SUN forums. It's their code that hit an internal error
of unspecified nature.
> Do these "reactor worker threads" have a limited shelf life,
> and have to be "exercised" every once it a while?
As with all worker threads: if they fail to work, throw them away
and replace them. But you may want to know why the worker failed.
Because if there's something wrong in the environment, the newly
started ones will also fail.
> Why isn't Throwable caught and handled in SSLServerIOEventDispatch?
Because a general Throwable is not an IO event. It's an IO event
if the other side closes the connection, or if there is a timeout
on network communication. But an internal error somewhere? That
can mean anything from a parse error because somebody sent plain
HTTP on an SSL port to an OutOfMemory or ClassNotFound condition
that really crashes your application.
> Wouldn't it make sense to convert it to a IOException so the application
> can be notified that there was a problem ("this.handler.exception(new
> IOException("Unknown exception", throwable));sslSession.shutdown();")?
See above... who are we to decide whether that makes sense?
Maybe it's a problem with the data being received, maybe it's
a problem with the setup of the SSL keys and certificates.
One can reasonably be considered an IO problem, the other cannot.
Runtime exceptions should be dealt with by application code
on a case-by-case basis. General throwables should generally
be dealt with by stopping the application.
The framework will not make such decisions for you. If you
feel that these exceptions should be mapped, plug in your
code for exception mapping. If there is no suitable plug-in
point, ask for it here or on our dev list.
> If for some reason it just isn't considered acceptable to convert a
> RuntimeException to an IOException, how do I detect this situation
> and recover from it?
The guys who know the NIO code will answer those questions.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org