Hi David, As Thierry pointed out, Representation#release() will close the stream immediately in your case. You can't expect ClientResource#release to do it for you as it would have to keep track of all requests sent by it and pending processing. However Response#release() will call it if an entity is set.
Also, Representation#getText() and Representation#exhaust() shouldn't systematically release the representation as it would prevent it from being reuse several time. All representations are not transient, like the FileRepresentation class which can be used several times as getText(), getStream() and other method will be able to serve fresh content several times. Hope this clarifies. Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -----Message d'origine----- De : David Fogel [mailto:[email protected]] Envoyé : mardi 13 juillet 2010 00:12 À : [email protected] Objet : Re: Problem with HttpClient extension (org.restlet.ext.httpclient) and unreleased connections during 404s A quick follow-up: Further testing shows this same hanging thread/running-out-of-connections problem happens with successful (200) GET requests, even if we call entity.exhaust() or clientResource.release(), both of which seem like likely candidates for successfully closing down the connections. Also, I notice that there is something called HttpIdleConnectionReaper, which looks like it's supposed to clean up idle connections, but even when we wait a while (> 15 seconds) between requests we still end up with all the connections in use and subsequent requests hanging. So far, the only thing that has worked, and _only_ on successful (200) requests, is to call entity.getStream().close(). Even calling entity.getText() does not release the connection- I guess something needs to close the inputstream... -Dave Fogel On Mon, Jul 12, 2010 at 4:43 PM, David Fogel <[email protected]> wrote: > Hi all- > > We've started using Restlet's HttpClient extension (along with Apache > HttpClient 4.01). > > We've hit what seems like a pretty big bug: when we make a client > request using the ClientResource API, if we GET a resource that does > not exist, that process seems to consume and never release an > HttpClient connection object. After GETing a few times with 404 > responses, all subsequent requests to that host will block forever. > Since the connection objects are pooled, and the default is 2, we are > seeing a hung system reproducibly on the 3rd attempt. > > I believe something like the following code will trigger this condition: > > ClientResource resource = new > ClientResource("http://www.restlet.org/DoesNotExist.html";); > Representation entity = null; > > // first time > try { > entity = resource.get(); > } catch (ResourceException re) { > re.printStackTrace(); // <---- this will show a 404 Status > } > //second time > try { > entity = resource.get(); > } catch (ResourceException re) { > re.printStackTrace(); // <---- this will show a 404 Status > } > // third time > try { > entity = resource.get(); // <---- this will hang forever! > } catch (ResourceException re) { > re.printStackTrace(); > } > > (Obviously our code is not actually like this- we would have these > multiple client GET requests triggered by use of our web app's > resources, which are in turn fetching some (often absent) data from > another server.) > > Since we don't have an entity in a response, we can't call > representation.exhaust() on it, and when we add finally() clauses to > the above which call resource.release(), nothing is different. (I'm > not clear at all under what circumstances we're supposed to call > ClientResource.release(), but it didn't help.) > > The problem goes away when we turn off the org.restlet.ext.httpclient > extension and use the built-in client connectors. We'd prefer to use > HttpClient, since we have a dependency on it anyhow from other code in > our system. (Is the built-in client connector production-ready? Will > it scale up to many concurrent requests?) > > Any suggestions? > > Thanks, > -Dave Fogel > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2632456 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2634674
