Re: Disabling pooling of PoolingConnectionManager

Hi, I both added "Connection close" header to my requests and NoConnectionReuseStrategy to my HttpClient. (via the builder) However, I started seeing the Socket Resets now. (which I assume means HttpClient tries to use an already existing connection which is already closed, (it is not connection

Re: Disabling pooling of PoolingConnectionManager

it seems we cannot set a strategy to ClosableHttpClient. the only option remaining is the header settings. On Oct 18, 2016 10:41 AM, "Stefan Magnus Landrø" wrote: > You could do both. > > From my experience all serious http server implementations respect the >

Re: Disabling pooling of PoolingConnectionManager

You could do both. >From my experience all serious http server implementations respect the Connection: close header 2016-10-18 16:35 GMT+02:00 Murat Balkan : > I checked with the RFC and it seems if provided, "connection: close" header > is a MUST rather than SHOULD. So, it

Re: Disabling pooling of PoolingConnectionManager

I checked with the RFC and it seems if provided, "connection: close" header is a MUST rather than SHOULD. So, it should not up to server implementation. But I find the TTL and Strategy approaches safer as we have some kind of control over them. On Tue, Oct 18, 2016 at 10:26 AM, Stefan Magnus

Re: Disabling pooling of PoolingConnectionManager

Why would you think so? 2016-10-18 16:10 GMT+02:00 Murat Balkan : > Thanks Oleg, > One question. I think it would be up to server implementation whether to > take these parameters into account right? > Regards, > Murat > > On Tue, Oct 18, 2016 at 10:06 AM, Oleg Kalnichevski

Re: Disabling pooling of PoolingConnectionManager

Thanks Oleg, One question. I think it would be up to server implementation whether to take these parameters into account right? Regards, Murat On Tue, Oct 18, 2016 at 10:06 AM, Oleg Kalnichevski wrote: > On Mon, 2016-10-17 at 22:06 -0600, Bhowmik, Bindul wrote: > > Murat, > >

Re: Disabling pooling of PoolingConnectionManager

On Mon, 2016-10-17 at 22:06 -0600, Bhowmik, Bindul wrote: > Murat, > > On Mon, Oct 17, 2016 at 8:11 PM, Murat Balkan wrote: > > I see. I think that also means that I cannot share the ClosableHttpClient > > instance among multiple threads as each client can refer to one

Re: Disabling pooling of PoolingConnectionManager

Murat, On Mon, Oct 17, 2016 at 8:11 PM, Murat Balkan wrote: > I see. I think that also means that I cannot share the ClosableHttpClient > instance among multiple threads as each client can refer to one connection > manager instance. > > Can connectionreusestrategy be used so

Re: Disabling pooling of PoolingConnectionManager

I see. I think that also means that I cannot share the ClosableHttpClient instance among multiple threads as each client can refer to one connection manager instance. Can connectionreusestrategy be used so that the pooling connection manager will always return a new connection regardless of the

Re: Disabling pooling of PoolingConnectionManager

Murat, On Mon, Oct 17, 2016 at 12:58 PM, Murat Balkan wrote: > Hi Bindul, > Thanks for the answer. > I was thinking that using a shared connection manager will increase the > performance. What will be the implications of reusing the same > BasicHttpClientConnectionManager

Re: Disabling pooling of PoolingConnectionManager

Hi Bindul, Thanks for the answer. I was thinking that using a shared connection manager will increase the performance. What will be the implications of reusing the same BasicHttpClientConnectionManager instance? Regards, Murat On Mon, Oct 17, 2016 at 2:31 PM, Bhowmik, Bindul

Re: Disabling pooling of PoolingConnectionManager

Murat, On Mon, Oct 17, 2016 at 11:12 AM, Murat Balkan wrote: > Hi, > > We are using PoolingHttpClientConnectionManager to open up connections to > multiple URL's in different threads (via different HttpGet objects). > > The only reason we are using the

Disabling pooling of PoolingConnectionManager

Hi, We are using PoolingHttpClientConnectionManager to open up connections to multiple URL's in different threads (via different HttpGet objects). The only reason we are using the PoolingHttpClientConnectionManager is its' performance in multi-thread environments (as suggested by the