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:***@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
Post by Joan Balagueró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
Post by Joan Balagueró-----Mensaje original-----
de noviembre de 2018 15:01
Para: HttpClient User Discussion
Asunto: Re: RV: Migration from Async 4.1.3 to HttpClient 5
Post by Joan BalagueróThanks Oleg. One more thing about the max connections with
lax/strict pool. Our code to modify the number of max connections
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
Post by Joan BalagueróThanks,
Joan.
-----Mensaje original-----
8
de noviembre de 2018 11:04
Para: HttpClient User Discussion
Asunto: Re: RV: Migration from Async 4.1.3 to HttpClient 5
Post by Joan BalagueróHello Oleg,
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.
Post by Joan Balagueró2. Regarding the RetryHandler, below the method inherited from
http
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
Post by Joan BalagueróPost by Joan BalagueróPost by Joan Balagueró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?
https://github.com/apache/httpcomponents-client/blob/master/httpclient5/src/main/java/org/apache/hc/client5/http/impl/DefaultHttpRequestRetryHandler.java#L160
Post by Joan BalagueróPost by Joan BalagueróPost by Joan Balagueró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
"179.182"
wc -l
99
wc -l
101
wc -l
98
wc -l
25876
wc -l
61507
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
https://wiki.apache.org/HttpComponents/FrequentlyAskedConnectionManagementQuestions
Post by Joan BalagueróPost by Joan BalagueróOleg
-----------------------------------------------------------------
----
-----------------------------------------------------------------
----
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-***@hc.apache.org
For additional commands, e-mail: httpclient-users-***@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-***@hc.apache.org
For additional commands, e-mail: httpclient-users-***@hc.apache.org