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:[email protected]]
> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
