Thanks ernestw. You're probably right, but I'm going to have a closer
look and monitor the connections.
@victor. I've come across the connections per route params as well,
and specifying them won't make any difference in this case as that
does not effect how the connections are closed.
On Nov 18,
You also can use next params:
ConnPerRoute connPerRoute = new
ConnPerRouteBean(CONNECTION_PER_ROUTE);
ConnManagerParams.setMaxConnectionsPerRoute(params, connPerRoute);
Where CONNECTION_PER_ROUTE is number of simultanious connections to
the same host
On 18 Лис, 01:13, ernestw wrote:
> Hmmm.
Hmmm. I wouldn't use that solution. With Keep-alive you never
explicitly close your connections - consumeContent merely reads
everything in the response input/error stream and connections are
automatically closed when they are idle. Increasing the maximum
connections per route only gives you mor
My thinking was - If there is no obvious "close" method anywhere, and
all examples I've seen of the HttpClient do not mention a close/finish
type method then you would assume that it just handles it for you!
Looks like that is not always the case, at least in a timely fashion.
Thanks ernestw I'll
I've run into a similar issue which was solved by making sure to
always call consumeContent on the HttpEntity contained in the
HttpResponse object (regardless of the response code). HttpClient
tries to use keep-alive; if you don't consume every request before
they are returned to the ThreadSafeCli
5 matches
Mail list logo
