Mailing-List: contact httpcomponents-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <httpcomponents-dev@jakarta.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Subject: RE: HttpCore NIOSSL fatal exception
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <httpcomponents-dev@jakarta.apache.org>
In-Reply-To: <BLU122-W238910FDAD2363D4F1A4DBBF6D0@phx.gbl>
References: <BLU122-W8355E39960E58CC8EDB55BF760@phx.gbl>
	 <474CE28A.4040102@dubioso.net> <1196249751.11632.11.camel@okhost>
	 <BLU122-W32C45176FE23D80AA8805BBF6C0@phx.gbl>
	 <19196d860712031239m554e11d4n8d778187acb0bb86@mail.gmail.com>
	 <BLU122-W238910FDAD2363D4F1A4DBBF6D0@phx.gbl>
Content-Type: text/plain
Date: Wed, 05 Dec 2007 14:13:00 +0100
Message-Id: <1196860380.27075.12.camel@okhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


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