RE: RV: Migration from Async 4.1.3 to HttpClient 5
Hi Oleg,
After applying the route in concrete now TEST5 works, but TEST3 still works in
the same way as the previous test. I have tried TEST3 with the Async 4.1.3 and
the result is the same, when you decrease the max connections value the pool
still reuses connections and does not honor the maxconn parameter.
Adding routes is not feasible in our use case, so at the moment we will provoke
a pool restart in case a user changes the max connections in a lax pool.
Thanks for your time,
Joan.
-Mensaje original-
De: Oleg Kalnichevski [mailto:ol...@apache.org]
Enviado el: sábado, 10 de noviembre de 2018 19:30
Para: HttpClient User Discussion
Asunto: Re: RV: Migration from Async 4.1.3 to HttpClient 5
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: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.
> >
>
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 [mail
Re: RV: Migration from Async 4.1.3 to HttpClient 5
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: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.
> >
>
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: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);
> > > }
>
Re: RV: Migration from Async 4.1.3 to HttpClient 5
On Fri, Nov 9, 2018 at 7:01 AM Oleg Kalnichevski wrote:
> 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.
>
Hi,
Can you make sure this is Javadoc'd in the right places if it is not
already?
Gary
>
> 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 ~]# n
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 thi
RE: RV: Migration from Async 4.1.3 to HttpClient 5
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.
-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
&g
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
RE: RV: Migration from Async 4.1.3 to HttpClient 5
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
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
