Re: Use of connection managers max-per-host, max-total settings; persistent connections

[Oleg Kalnichevski <ol...@apache.org>]

On Thu, 2008-09-18 at 14:56 -0700, Tatu Saloranta wrote:
> I have tried to figure out exact relationship between settings that limit per-connection manager number of connections: maximum connections to open/retain per-host, and max connections overall.
> I read documentation on web site, apologies if I missed an obvious answer.
> 

Hi Tatu

I am sorry it took me so long to get back to you.

> Specifically, I am trying to figure out whether there is any difference between using persistent connections and not. Right now I assume there is no difference -- persistent connections are just held onto in hopes they may be reused, but either way, these are hard limits for all connections (per-host and total).
> 

This limitation no longer applies to HttpClient 4.0, where only
persistent connections are kept in the pool. Closed connections are
discarded upon release.


> But what I really would be able to figure out is this: is there a way to limit number of persistent (keep-alive) connections to lower value than hard-limit on number of connections that can be opened?
> Basically so that limit to check against when opening a connection would be higher (say, 10), but limit to check when deciding whether client will keep the connection would be lower (say, 2). This would allow for temporary opening of higher number of concurrent connections during load spikes, without leaving higher number of open connections.
> 

I do not see a problem with that, but you would have to subclass
ConnPoolByRoute and override #freeEntry method

> I guess alternative way would be to just use aggressive values for closing free open connections.
> 

I personally think this is a better solution. Just evict idle
connections more aggressively. That is it.

Hope this helps

Cheers

Oleg


> I appreciate any suggestions,
> 
> -+ Tatu +-
> 
> 



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


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

Re: Use of connection managers max-per-host, max-total settings; persistent connections

[Tatu Saloranta <co...@yahoo.com>]

--- On Sun, 9/21/08, Oleg Kalnichevski <ol...@apache.org> wrote:

> Hi Tatu
> 
> I am sorry it took me so long to get back to you.

No problem at all, it's pretty quick answer compared to many other lists. :-)

> > Specifically, I am trying to figure out whether there
> is any difference between using persistent connections and
> not. Right now I assume there is no difference -- persistent
> connections are just held onto in hopes they may be reused,
> but either way, these are hard limits for all connections
> (per-host and total).
> > 
> 
> This limitation no longer applies to HttpClient 4.0, where only
> persistent connections are kept in the pool. Closed connections are
> discarded upon release.

Ok. The system in question uses 3.1 (they actually only recently upgraded from 2.0). But I hope it can be upgrade to 4.0 in few months.

> > Basically so that limit to check against when opening
> a connection would be higher (say, 10), but limit to check
> when deciding whether client will keep the connection would
> be lower (say, 2). This would allow for temporary opening of
...
> 
> I do not see a problem with that, but you would have to
> subclass ConnPoolByRoute and override #freeEntry method

Ok thanks for the pointer.

> > I guess alternative way would be to just use aggressive values for closing free open connections.
> 
> I personally think this is a better solution. Just evict idle
> connections more aggressively. That is it.

That makes sense, I think I'll focus on this approach then.

Also, after thinking it through, I also realized that the real problem may be server-side handling of persistent connections, not clients. Tomcat 5.5 seems to have very limited control over lifetime of persistent connections. :-/
(6.0 has little bit more control for the default connector, plus nio-based alternatives that might help).

Thanks for the help!

-+ Tatu +-



      

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