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? 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