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); } 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. > 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
