Hi Oleg, After applying the route in concrete now TEST5 works, but TEST3 still works in the same way as the previous test. I have tried TEST3 with the Async 4.1.3 and the result is the same, when you decrease the max connections value the pool still reuses connections and does not honor the maxconn parameter.
Adding routes is not feasible in our use case, so at the moment we will provoke a pool restart in case a user changes the max connections in a lax pool. Thanks for your time, Joan. -----Mensaje original----- De: Oleg Kalnichevski [mailto:ol...@apache.org] Enviado el: sábado, 10 de noviembre de 2018 19:30 Para: HttpClient User Discussion Asunto: Re: RV: Migration from Async 4.1.3 to HttpClient 5 On Sat, 2018-11-10 at 18:02 +0100, Joan Balagueró - ventusproxy wrote: > Hello Oleg, > > Sorry, but I think I'm going to need a bit more help to finish > understand this ... This was my test: > > a. A load of around 2000 req/s > b. Just 1 route = http://54.38.179.182:8080 c. Every time we change > the max_connections value this method is > executed: > public void setMaxConnections(int maxConnections) { > this.phccm.setMaxTotal(maxConnections); > this.phccm.setDefaultMaxPerRoute(maxConnections); > } You might want to add this.phccm.setMaxPerRoute(new HttpRoute(new HttpHost("54.38.179.182", 8080)), maxConnections); this.phccm.setDefaultMaxPerRoute(maxConnections) > d. Printing stats every 1s: > public void printStats() { > System.out.println("Stats total: " + > this.phccm.getTotalStats().getLeased() + " / " + > this.phccm.getTotalStats().getMax()); > System.out.println("Stats route: " + this.phccm.getStats(new > HttpRoute(new HttpHost("54.38.179.182", 8080, > "http"))).getLeased() + " / " + this.phccm.getStats(new HttpRoute(new > HttpHost("54.38.179.182", 8080, "http"))).getMax()); > } > > > TEST 1. Strict pool, max connections = 1, keep-alive = 1s, pool > timeout = 1m > - almost all requests end up with max connections error > - Stats total = Stats route = 1 / 1 > --> So test ok. > > TEST 2. Strict pool, max connections = 5000 (value changed > without restarting pool), keep-alive = 1s, pool timeout = 1m > - all requests processed ok > - Stats total = Stats route ~ 1030 / 5000 > --> So test ok. > > TEST 3. Strict pool, max connections = 1 (value changed without > restarting pool), keep-alive = 1s, pool timeout = 1m > - some requests processed ok, some returning max connections error > - Stats total = Stats route ~ n / 1, with 'n' lowering slowly from > 1.030 to .... > --> It seems that even with a maxConn = 1 the pool is reusing pooled > connections. > > TEST 4: Lax pool, max connections = 1, POOL RESTARTED before > sending traffic, keep-alive = 1s, pool timeout = 1m > - almost all requests end up with max connections error > - Stats total = Stats route = 1 / 1 (sometimes 2 / 1, ok because it's > lax). > --> So test ok. > > TEST 5. Lax pool, max connections = 5000 (value changed without > restarting pool), keep-alive = 1s, pool timeout = 1m > - almost all requests end up with max connections error > - Stats total = Stats route = 1 / 1 (sometimes 2 / 1). > > > So my doubts are: > > 1. Is TEST 3 ok? Even having pooled connections to reuse, shouldn't > the max_conn value have preference? > > 2. Is TEST 5 ok? It seems the 'DefaultMaxPerRoute' cannot be applied > on the fly in a lax pool. It should have a value of 5000 but it's > preserving the previous value of 1 (test 4). > > > > Thanks , > > Joan. > > > > -----Mensaje original----- > De: Oleg Kalnichevski [mailto:ol...@apache.org] Enviado el: viernes, 9 > de noviembre de 2018 15:31 > Para: HttpClient User Discussion > Asunto: Re: RV: Migration from Async 4.1.3 to HttpClient 5 > > On Fri, 2018-11-09 at 15:19 +0100, Joan Balagueró wrote: > > Ok, so if I have a defaultMaxPerRoute = 1, and all requests I'm > > sending are using plain http to the same ip (without proxy) and only > > using 4 different ports (8080, 8081, 8082, 8083), than this means I > > have 1 max connection for ip:8080, 1 for ip:8081, 1 for ip:80802 and > > 1 for ip:80803? > > Joan. > > > defaultMaxPerRoute applies only once when the per route pool is created. I guess this is what skews the results of TEST 3 and TEST 5. Oleg > Correct. > > Oleg > > > -----Mensaje original----- > > De: Oleg Kalnichevski [mailto:ol...@apache.org] Enviado el: > > viernes, 9 > > de noviembre de 2018 15:01 > > Para: HttpClient User Discussion > > Asunto: Re: RV: Migration from Async 4.1.3 to HttpClient 5 > > > > On Fri, 2018-11-09 at 13:39 +0100, Joan Balagueró wrote: > > > Thanks Oleg. One more thing about the max connections with > > > lax/strict pool. Our code to modify the number of max connections > > > is: > > > > > > public void setMaxConnections(int maxConnections) { > > > this.phccm.setMaxTotal(maxConnections); > > > this.phccm.setDefaultMaxPerRoute(maxConnections); > > > } > > > > > > If I modify (on the fly) the max connections in a strict pool it > > > works. For example I set a very low value and I start to receive > > > DeadlineTimeoutException, when I set a higher value the error > > > disappears. If I print the pool.getMaxTotal() I get the right > > > value. > > > > > > But this does not work with a lax pool. I set up a lax pool with > > > max connections = 1, and no DeadlineTimeoutException is thrown > > > (with the same load). When I print the maxTotal and > > > defaultMaxPerRoute I get > > > 0 > > > and 1 (instead of 1 and 1). > > > > > > Is this a bug or am I missing something? > > > > > > > Max total is not enforced by the lax pool, only max per route. > > > > Oleg > > > > > > > Thanks, > > > > > > Joan. > > > > > > > > > -----Mensaje original----- > > > De: Oleg Kalnichevski [mailto:ol...@apache.org] Enviado el: > > > jueves, > > > 8 > > > de noviembre de 2018 11:04 > > > Para: HttpClient User Discussion > > > Asunto: Re: RV: Migration from Async 4.1.3 to HttpClient 5 > > > > > > On Wed, 2018-11-07 at 19:30 +0100, Joan Balagueró wrote: > > > > Hello Oleg, > > > > > > > > We are finishing the migration and have the last questions: > > > > > > > > 1. If a connection is kept-alive for 30s at second 0, and after > > > > 10s is reused, this connection will die at second 30 or will > > > > survive until second 40? > > > > > > Keep-alive value is always relative to the last connection > > > release. > > > If you want to limit the absolute connection life time please use > > > set a finite TTL (total time to live) value. > > > > > > > > > > > 2. Regarding the RetryHandler, below the method inherited from > > > > http > > > > 4.5 and modified to work with http5: > > > > > > > > > > I would recommend using DefaultHttpRequestRetryHandler shipped > > > with the library unless you have some application specific > > > requirements. > > > > > > > > > > > > https://github.com/apache/httpcomponents-client/blob/master/httpclient5/src/main/java/org/apache/hc/client5/http/impl/DefaultHttpRequestRetryHandler.java#L160 > > > > > > > public boolean retryRequest(HttpRequest request, IOException > > > > exception, int executionCount, HttpContext context) { > > > > // Don't retry if max retries are reached. > > > > if (executionCount > this.maxExecutionCount) return false; > > > > > > > > // Don't retry if any of these exceptions occur. > > > > if (exception instanceof InterruptedIOException || exception > > > > instanceof UnknownHostException || exception instanceof > > > > ConnectException || exception instanceof SSLException) return > > > > false; > > > > > > > > // Retry of if this request is considered 'idempotent'. > > > > return (!(request instanceof HttpEntityEnclosingRequest)); } > > > > > > > > I understand the first two conditions are still ok (not sure if > > > > we have to add new exceptions on that list) but regarding the > > > > last condition,what would the equivalent condition be in Http5? > > > > > > > > > > I would suggest the following: > > > > > > > > > > > > https://github.com/apache/httpcomponents-client/blob/master/httpclient5/src/main/java/org/apache/hc/client5/http/impl/DefaultHttpRequestRetryHandler.java#L160 > > > > > > > > > > > > > > 3. We have increased the response time of our backend (ip ended > > > > with > > > > '182') in order to exhaust the strict/lax pool. When this > > > > happens the pool starts to throw a DeadlineTimeoutException. At > > > > this moment the number of sockets in TIME_WAIT increases a lot > > > > until making the server unresponsive (probably exhausting the > > > > local > > > > ports): > > > > > > > > [root@ns3103538 ~]# netstat -anp | grep TIME_WAIT | grep > > > > "179.182" > > > > > > > > > > > > > wc -l > > > > 99 > > > > [root@ns3103538 ~]# netstat -anp | grep TIME_WAIT | grep > > > > "179.182" > > > > > > > > > > > > > wc -l > > > > 101 > > > > [root@ns3103538 ~]# netstat -anp | grep TIME_WAIT | grep > > > > "179.182" > > > > > > > > > > > > > wc -l > > > > 98 > > > > [root@ns3103538 ~]# netstat -anp | grep TIME_WAIT | grep > > > > "179.182" > > > > > > > > > > > > > wc -l > > > > 25876 > > > > [root@ns3103538 ~]# netstat -anp | grep TIME_WAIT | grep > > > > "179.182" > > > > > > > > > > > > > wc -l > > > > 61507 > > > > [root@ns3103538 ~]# netstat -anp | grep TIME_WAIT | grep > > > > "179.182" > > > > > > > > > > > > > wc -l > > > > 97615 > > > > > > > > Is this the right behaviour? If Http5 cannot create new > > > > connections, so no new sockets are opened, why does the number > > > > of sockets in TIME_WAIT raise at those values? > > > > > > > > > > I believe it is. There is pretty good explanation of what the > > > TIME_WAIT state represents in our old wiki: > > > > > > > > > > > > https://wiki.apache.org/HttpComponents/FrequentlyAskedConnectionManagementQuestions > > > > > > Oleg > > > > > > > > > > > > ----------------------------------------------------------------- > > > ---- > > > To unsubscribe, e-mail: > > > httpclient-users-unsubscr...@hc.apache.org > > > For additional commands, e-mail: > > > httpclient-users-h...@hc.apache.org > > > > > > > > > > > > > > > ----------------------------------------------------------------- > > > ---- > > > To unsubscribe, e-mail: > > > httpclient-users-unsubscr...@hc.apache.org > > > For additional commands, e-mail: > > > httpclient-users-h...@hc.apache.org > > > > > > > > > ----------------------------------------------------------------- > > ---- > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > > For additional commands, e-mail: > > httpclient-users-h...@hc.apache.org > > > > > > > > > > ----------------------------------------------------------------- > > ---- > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > > For additional commands, e-mail: > > httpclient-users-h...@hc.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
