On Mon, 2015-01-05 at 14:38 +0100, Stéphane Nicoll wrote: > Hi Oleg, > > Thanks for the fast reply! > > On Mon, Jan 5, 2015 at 1:11 PM, Oleg Kalnichevski <[email protected]> wrote: > > > On Mon, 2015-01-05 at 10:57 +0100, Stéphane Nicoll wrote: > > > Hi, > > > > > > Is there a way to properly dispose the resources of a connection > > regardless > > > of the "mode" (i.e. persistent or non persistent). Using HC 4.3 > > > > > > > Hi Stéphane > > > > CloseableHttpResponse#close is what you want. > > > > It looks like that's what we are doing already: > https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/java/org/springframework/http/client/HttpComponentsClientHttpResponse.java#L90 >
Looks perfectly reasonable to me. Cheers Oleg > I'll have to ask a sample project to that user then. Thanks! > > S. > > > > > > > > > The doc states what we should do in both cases[1] but I don't see an > > > obvious way to close the connection when we should and just leave it open > > > when the client uses persistent connections. > > > > > > > There are no connection re-use 'modes' as far as I can tell. HttpClient > > keeps connections alive as long as they are (1) declared as persistent > > (by protocol version or explicit 'Connection' header) and (2) are known > > to be in a consistent state. It is generally recommended for the client > > side to consume response content in order to maximize chances of the > > connection getting re-used. > > > > Hope this helps > > > > Oleg > > > > > > > This is related to SPR-12524[2] > > > > > > Thanks! > > > S. > > > > > > [1] > > > > > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/fundamentals.html > > > [2] https://jira.spring.io/browse/SPR-12524 > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
