Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Subject: Re: HttpClient 4, I/O exception and
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <dev@hc.apache.org>
In-Reply-To: <200806061608.12187.m.zdila@mwaysolutions.com>
References: <200806040940.44490.m.zdila@mwaysolutions.com>
	 <200806061543.23666.m.zdila@mwaysolutions.com>
	 <1212760680.9179.32.camel@ubuntu>
	 <200806061608.12187.m.zdila@mwaysolutions.com>
Content-Type: text/plain; charset=utf-8
Date: Fri, 06 Jun 2008 16:27:01 +0200
Message-Id: <1212762421.9179.41.camel@ubuntu>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit

On Fri, 2008-06-06 at 16:08 +0200, Martin Zdila wrote:
> > > i would be happy if we could find out why those "I/O Exception"s are
> > > occuring and to fix it.
> >
> > Most likely this is because the connection timed out on the server side.
> > The target server dropped it, but the JVM on the client-side failed to
> > detect it. Next time the connection is retrieved from the pool and
> > re-used on the client side it blows up an I/O exception. This appears to
> > be a local connectivity problem, something I was trying to tell all
> > along.
> 
> So are those "I/O Exception" absolutely normal and expected actually?

Connectivity problems are absolutely normal and are to be expected

>  Or 
> should JVM on the client-side be able to detect it?
> 

A ﻿fundamental problem with classic / blocking I/O is that the _only_
way to find out if the socket is still open is to read from it. This is
what the stale connection check is meant to do, but it cannot be 100%
reliable.

> It would be nice if HttpClient could detect it somehow if it is possible.

It would also be great if HttpClient could walk my dog


>  I 
> think I had no such problem in HttpClient 3. Or maybe I just didn't notice 
> that ;-)
> 

You did not notice.

This is what I recommend you do: close idle connections more
aggressively, for instance, after 5 seconds of inactivity. This will
reduce the change of idle connections being closed on the server without
the client-side noticing.

Oleg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org