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ø" <stefan.lan...@gmail.com> wrote: > 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-unsubscribe@ > 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-help@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 >
