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)
Date: Tue, 1 Nov 2011 15:03:12 +0100
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <dev@hc.apache.org>
Subject: Re: Too Many Open Files Exception
Message-ID: <20111101140312.GA16761@ok2cons2.nine.ch>
References: 
 <CAB_f4-WpWydDuCve3Aoq++TQ53apYvgqU=6Tux2CkCFLRnR2Lg@mail.gmail.com>
 <1320096651.3612.16.camel@ubuntu>
 <CAB_f4-WYq12wDeihKC+K9j5VSS7o1h4UP9m7pGCMOMdqv+jSwA@mail.gmail.com>
 <1320100109.3612.23.camel@ubuntu>
 <CAB_f4-XxAxNqU_tQzVuY-3LsmE4xnyHXtr0A8ZDENy-+LNgJ1Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAB_f4-XxAxNqU_tQzVuY-3LsmE4xnyHXtr0A8ZDENy-+LNgJ1Q@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)

On Tue, Nov 01, 2011 at 09:29:57AM -0400, Bill Speirs wrote:
> > Correct. The difference is that EntityUtils#consume will try to salvage
> > the underlying connection, whereas HttpUriRequest#abort will not.
> >
> > The important point is to use try-finally to ensure connection release
> > in all cases.
> 
> The problem is that I have two methods to "close" the connection: one
> if everything is fine, another if there is an error/exception. So
> try-catch-finally doesn't really help. I think what I want is the
> following. In the normal case (the try block), I simply get the entity
> and close the input stream on the content. However, if something goes
> wrong I should simply call abort() on the request.
> 
> try {
>   response = client.execute(request);
>   response.getEntity().getContent().close();
> } catch( ... ) {
>   request.abort();
> }
> 
> Does this make sense?
>

Yes, it does, as long as you also catch runtime exceptions.

 
> I suppose moving response.getEntity().getContent().close(); to a
> finally block couldn't hurt, as I don't expect the input stream would
> throw an exception after abort() was called... but it seems messy.
> 
> I guess I'm not sure why there isn't simply a close() method for the
> request which can be called in either case.
> 

Good ol' #releaseConnection() method will be back in HttpClient 4.2


> > HttpClient automatically shuts down the underlying connection in case of
> > an I/O exception including a timeout. The connection manager will evict
> > closed connection immediately upon release.
> 
> That isn't what I'm seeing, although it's tough to reproduce. On two
> separate machines running the same code I'm seeing the following:
> 
> try {
>   HttpResponse response = client.execute(httpHost, request); // throws
> a java.net.SocketTimeoutException
> } catch(IOException e) {
>   request.abort();
> }
> 

This code is likely to leak connections in case of a runtime (unchecked) exception.

Oleg

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