Hello,

Then having 1 pool is perfect. My proxy is a reverse proxy. All incoming 
requests of these 20 webservices are load-balanced by our proxy to 15 servers. 
So I only have 15 ips, because port is always 8080. All requests are http (no 
https), no security credentials and no proxies in the middle of communication.

In this conditions I suppose that connections will be shared. Is it true?

Anyway, I'll enable debug to check that.

Thanks,
Joan.


-----Mensaje original-----
De: Oleg Kalnichevski [mailto:[email protected]] 
Enviado el: viernes, 15 de junio de 2012 17:58
Para: HttpClient User Discussion
Asunto: RE: Question about pools

On Fri, 2012-06-15 at 17:52 +0200, Joan Balaguero wrote:
> Hello Oleg,
> 
> Then, if I have one webservice pointing to http://ip1:port1/webservice1 and 
> another one pointing to http://ip1:port1/webservice2, connections of ws1 can 
> be shared with connections of ws2?
> 

Yes

> What are the conditions for sharing 2 connections? Just the same ip and port? 
> Or exactly the same url (end point)?
> 

They must have the same route (host, port, security guarantees, and 
intermediate proxy hops). Path and query parts of the request URI make no 
difference for connection pooling.

Oleg

> Thanks,
> 
> Joan.
> 
> -----Mensaje original-----
> De: Oleg Kalnichevski [mailto:[email protected]] Enviado el: viernes, 
> 15 de junio de 2012 17:41
> Para: HttpClient User Discussion
> Asunto: Re: Question about pools
> 
> On Thu, 2012-06-14 at 13:08 +0200, Joan Balaguero wrote:
> > Hello,
> > 
> >  
> > 
> > I have a servlet that acts as a http proxy. It manages 20 
> > webservices, and each webservice has its own Multithreaded pool. The 
> > total number of concurrent connections is not higher than 2.000.
> > 
> >  
> > 
> > I’m thinking to use just one pool for all 20 webservices. 
> > 
> >  
> > 
> > I’ve not made any tests yet, but what would be the advantages and 
> > disadvantages of using just one pool?
> > 
> >  
> > 
> > I suppose that I’ll earn resources (thread pools, etc) but this 2000 
> > requests, that now are shared among 20 pools,  they’ll be served by 
> > just one pool. Can I find any lock contentions or something that 
> > makes this change not recommendable? Anyone using a pool with 2000 
> > (or more) concurrent requests? Or maybe I should try asyncHttpClient with 
> > this level of requests.
> > 
> >  
> > 
> 
> Joan
> 
> It really depends on several factors. Connections pools in HttpClient 4..x 
> are protected with one global lock per pool. So, the larger the pool the more 
> likely are chances of lock contention. However, as long as the number of 
> worker threads is approximately the same as the max number of connections per 
> route, the lock should get acquired and released reasonably fast. 
> 
> At the same time if all your web services are hosted on different hosts with 
> distinct connection routes, connections cannot be shared between endpoints, 
> so you might as well have separate pools of connections for each individual 
> service.
> 
> Oleg
> 
> 
> 
> > Thanks,
> > 
> > Joan.
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> 
> -----
> No se encontraron virus en este mensaje.
> Comprobado por AVG - www.avg.com
> Versión: 2012.0.2180 / Base de datos de virus: 2433/5070 - Fecha de 
> publicación: 06/14/12
> 
> 
> ---------------------------------------------------------------------
> 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]


-----
No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com
Versión: 2012.0.2180 / Base de datos de virus: 2433/5070 - Fecha de 
publicación: 06/14/12


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to