Re: AW: Controlling releaseConnection

2016-10-18 Thread Oleg Kalnichevski
On Tue, 2016-10-18 at 01:46 +0200, e...@zusammenkunft.net wrote: > Hello, > > Can younspecify why you need to delay it? Do wou want to make some kind of > rate limit with this or optimize pipelining? > > Gruss > Bernd I am not quite sure I understand the problem. HttpClient releases connection

Re: Disabling pooling of PoolingConnectionManager

2016-10-18 Thread Oleg Kalnichevski
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 connection > > manager inst

Re: Disabling pooling of PoolingConnectionManager

2016-10-18 Thread 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 wrote: > On Mon, 2016-10-17 at 22:06 -0600, Bhowmik, Bindul wrote: > > Murat, > > > > On Mon, Oct 17,

RE: Controlling releaseConnection

2016-10-18 Thread Pellerin, Clement
I agree that code is correct. I never said there was a bug. I am asking how to override the behavior. We are porting our product from HttpClient 4.1 to 4.5.2 and we need to preserve that feature because it is used by our customers. It would be a shame to duplicate all of MainClientExec because of a

Re: Disabling pooling of PoolingConnectionManager

2016-10-18 Thread Stefan Magnus Landrø
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 > wrote: > > > On Mon

Re: Disabling pooling of PoolingConnectionManager

2016-10-18 Thread Murat Balkan
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 Landr

Re: Disabling pooling of PoolingConnectionManager

2016-10-18 Thread Stefan Magnus Landrø
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 should not up to serv

Re: Controlling releaseConnection

2016-10-18 Thread Oleg Kalnichevski
On Tue, 2016-10-18 at 10:12 -0400, Pellerin, Clement wrote: > I agree that code is correct. I never said there was a bug. > I am asking how to override the behavior. > We are porting our product from HttpClient 4.1 to 4.5.2 > and we need to preserve that feature because it is used by our customers.

Re: Disabling pooling of PoolingConnectionManager

2016-10-18 Thread Murat Balkan
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 > Connection: close header > > 2016-1