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