hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Berlin" <sber...@gmail.com>
Subject Re: HttpCore NIOSSL fatal exception
Date Wed, 05 Dec 2007 16:39:01 GMT
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 <olegk@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 <buddhabuddy@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


Mime
View raw message