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 <mrbal...@gmail.com>: > 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ø < > stefan.lan...@gmail.com> wrote: > > > Why would you think so? > > > > 2016-10-18 16:10 GMT+02:00 Murat Balkan <mrbal...@gmail.com>: > > > > > 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 <ol...@apache.org> > > > wrote: > > > > > > > On Mon, 2016-10-17 at 22:06 -0600, Bhowmik, Bindul wrote: > > > > > Murat, > > > > > > > > > > On Mon, Oct 17, 2016 at 8:11 PM, Murat Balkan <mrbal...@gmail.com> > > > > 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 that the pooling > connection > > > > manager > > > > > > will always return a new connection regardless of the route > > provided? > > > > > > > > > > I did not think about that, guess you could use the > > > > NoConnectionReuseStrategy > > > > > > > > > > > > > That would be one option. Another option is to manually evict > > persistent > > > > connections from the pool after each transaction. Another option is > to > > > > set connection TTL (total time to live) to some very low value. > Another > > > > option is to simply use 'connection: close' request header. > > > > > > > > Oleg > > > > > > > > > - Bindul > > > > > > > > > > > > > > > > > Regards. > > > > > > Murat > > > > > > > > > > > > On Mon, Oct 17, 2016 at 5:05 PM, Bhowmik, Bindul < > > > > bindulbhow...@gmail.com> > > > > > > wrote: > > > > > > > > > > > >> Murat, > > > > > >> > > > > > >> On Mon, Oct 17, 2016 at 12:58 PM, Murat Balkan < > > mrbal...@gmail.com> > > > > 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 instance? > > > > > >> > > > > > >> If you see the documentation for the > > BasicHttpClientConnectionManag > > > er > > > > > >> [1], you will see that it only maintains one active connection. > If > > > you > > > > > >> share the the instance, your requests will be waiting for the > > > > > >> connection to be available and that will be your bottleneck. > > > > > >> > > > > > >> I would also recommend reading the connection management section > > of > > > > > >> the Http Client documentation [2] > > > > > >> > > > > > >> - Bindul > > > > > >> > > > > > >> [1] http://hc.apache.org/httpcomponents-client-ga/ > > > > > >> httpclient/apidocs/org/apache/http/impl/conn/ > > > > > >> BasicHttpClientConnectionManager.html > > > > > >> [2] http://hc.apache.org/httpcomponents-client-4.5.x/ > > > > > >> tutorial/html/connmgmt.html > > > > > >> > > > > > >> > Regards, > > > > > >> > Murat > > > > > >> > > > > > > >> > On Mon, Oct 17, 2016 at 2:31 PM, Bhowmik, Bindul < > > > > > >> bindulbhow...@gmail.com> > > > > > >> > wrote: > > > > > >> > > > > > > >> >> Murat, > > > > > >> >> > > > > > >> >> On Mon, Oct 17, 2016 at 11:12 AM, Murat Balkan < > > > mrbal...@gmail.com > > > > > > > > > > >> 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 > > PoolingHttpClientConnectionMan > > > > ager > > > > > >> is > > > > > >> >> its' > > > > > >> >> > performance in multi-thread environments (as suggested by > the > > > > > >> >> > documentation). > > > > > >> >> > > > > > > >> >> > However, we are not interested in the actual "pooling" > > > > functionality. > > > > > >> >> > That's to say, we want to open up a brand new connection > even > > > if > > > > the > > > > > >> >> route > > > > > >> >> > is the same. > > > > > >> >> > > > > > >> >> The performance enhancements you achieve from > > > > > >> >> PoolingHttpClientConnectionManager are due to its connection > > > > pooling > > > > > >> >> feature, that saves you to cost of establishing the > connection > > > when > > > > > >> >> another request goes to the same route. > > > > > >> >> > > > > > >> >> > > > > > > >> >> > How can we achieve this? We tried to set maxPerroute to 1 > but > > > it > > > > > >> seems it > > > > > >> >> > is not the correct way. > > > > > >> >> > > > > > >> >> I have not tested, but setting maxPerRoute to 1 would degrade > > > > > >> >> performance for you as you will have a number of Http clients > > > > waiting > > > > > >> >> for the single connection. > > > > > >> >> > > > > > >> >> If you do not want to use pooled connections, you can use > > > > > >> >> BasicHttpClientConnectionManager and not share it. > > > > > >> >> > > > > > >> >> > > > > > > >> >> > Regards, > > > > > >> >> > Murat > > > > > >> >> > > > > > >> >> ------------------------------------------------------------ > > > > --------- > > > > > >> >> To unsubscribe, e-mail: httpclient-users-unsubscribe@ > > > hc.apache.org > > > > > >> >> For additional commands, e-mail: httpclient-users-help@hc. > > > > apache.org > > > > > >> >> > > > > > >> >> > > > > > >> > > > > > > >> > > > > > > >> > -- > > > > > >> > Murat Balkan > > > > > >> > > > > > >> ------------------------------------------------------------ > > > --------- > > > > > >> To unsubscribe, e-mail: httpclient-users-unsubscribe@ > > hc.apache.org > > > > > >> For additional commands, e-mail: httpclient-users-help@hc. > > > apache.org > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > -- > > > > > > Murat Balkan > > > > > > > > > > ------------------------------------------------------------ > > --------- > > > > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > > > > > For additional commands, e-mail: httpclient-users-help@hc. > apache.org > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------ > --------- > > > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > > > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > > > > > > > > > > > > > > > -- > > > Murat Balkan > > > > > > > > > > > -- > > BEKK Open > > http://open.bekk.no > > > > TesTcl - a unit test framework for iRules > > http://testcl.com > > > > > > -- > Murat Balkan > -- BEKK Open http://open.bekk.no TesTcl - a unit test framework for iRules http://testcl.com