Re: HttpServer on shutdown waits for entire grace period when client is connected using keep-alive
On Sun, 2020-08-09 at 20:24 +0200, Niklas Lochschmidt wrote: > Thank you, Oleg. Just to confirm. The code you send is equivalent to > just a lower grace period in the 4.x API, e.g. it will terminate > legitimate inflight connections as well, not only the idle > connections, right? Correct. > At least that is what I am seeing from my tests. > > Some background: I actually want to have one particular service built > on http4k, that is scaled up and back down to zero pretty frequently. > Sometimes it has to serve API requests that take up to 10 or 15 > seconds to complete (doing a larger amount of fan-out http requests > to other APIs). That means I would want to set a higher grace period > even, but that will mean the service will always take long to shut > down. > > Using http4k I can easily switch to a different server backend, but I > was using this one and was very happy with it's performance. Kudos > for that! > > Of course the "real" solution is to switch to a background worker > setup with queues, but so far it was unnecessary. > > If I can piece together a good testcase I'll open an issue on Jira. I > guess this would be something that would only land in 5.x and not be > backported into 4.x anymore? > We are not planning to add new features to 4.x or back-port features from 5.x. All our limited resources will have to allocated to building 5.1 and maintaining 5.0. Oleg > Niklas > > Oleg Kalnichevski schrieb am So., 9. Aug. 2020, > 13:00: > > On Fri, 2020-08-07 at 20:04 +0200, Niklas Lochschmidt wrote: > > > I am trying to use the graceful shutdown of HttpServer server > > for > > > http4k, using HttpCore 4.4.13 and 5.0.1. I am creating the server > > > simply > > > using `ServerBootstrap.bootstrap().register(...).create()` and > > > shutting > > > down with `shutdown(5, TimeUnit.SECONDS)` and > > > `close(CloseMode.GRACEFUL)` respectively. Here is what I am > > seeing: > > > > > > - When the server has never been requested it shuts down > > instantly > > > ✔️ > > > - When the server has been requested by a client without keep- > > alive > > > it > > > shuts down instantly ✔️ > > > - When the server has been requested by a client with keep-alive > > and > > > the > > > request is in-flight during shutdown it shuts down as soon as > > the > > > request is done ✔️ > > > > > > The problem is, when I connected with a client that uses keep- > > alive, > > > and > > > the request has been handled by the server and now the client is > > > holding > > > the connection open, then when I shutdown the server, the server > > > will > > > take the whole grace period to shutdown at which point the keep- > > > alive > > > connections are finally being force-closed. > > > > > > Is it possible to somehow speed up the shutdown also in this > > case > > > without terminating in-flight requests? Is there maybe a > > workaround > > > to > > > terminate all idle connections with keep-alives immediately > > before > > > shutdown? > > > > > > > The problem is there is no way of reliably testing whether a > > connection > > is idle or not, as connections can become active immediately after > > passing inactivity test. > > > > What could be a reasonable solution in many cases is to reduce the > > default grace period timeout. > > > > This will make the server await connection termination for 1 second > > instead of 5 seconds. > > ``` > > HttpServer server = ServerBootstrap.bootstrap().create(); > > server.initiateShutdown(); > > server.awaitTermination(TimeValue.ofSeconds(1)); > > server.close(CloseMode.IMMEDIATE); > > ``` > > > > Having said that there might be a better way to detect idle server- > > side > > connections as well. Feel free to raise a request in JIRA if you > > want > > me to look into that. > > > > Oleg > > > > - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: HttpServer on shutdown waits for entire grace period when client is connected using keep-alive
Thank you, Oleg. Just to confirm. The code you send is equivalent to just a lower grace period in the 4.x API, e.g. it will terminate legitimate inflight connections as well, not only the idle connections, right? At least that is what I am seeing from my tests. Some background: I actually want to have one particular service built on http4k, that is scaled up and back down to zero pretty frequently. Sometimes it has to serve API requests that take up to 10 or 15 seconds to complete (doing a larger amount of fan-out http requests to other APIs). That means I would want to set a higher grace period even, but that will mean the service will always take long to shut down. Using http4k I can easily switch to a different server backend, but I was using this one and was very happy with it's performance. Kudos for that! Of course the "real" solution is to switch to a background worker setup with queues, but so far it was unnecessary. If I can piece together a good testcase I'll open an issue on Jira. I guess this would be something that would only land in 5.x and not be backported into 4.x anymore? Niklas Oleg Kalnichevski schrieb am So., 9. Aug. 2020, 13:00: > On Fri, 2020-08-07 at 20:04 +0200, Niklas Lochschmidt wrote: > > I am trying to use the graceful shutdown of HttpServer server for > > http4k, using HttpCore 4.4.13 and 5.0.1. I am creating the server > > simply > > using `ServerBootstrap.bootstrap().register(...).create()` and > > shutting > > down with `shutdown(5, TimeUnit.SECONDS)` and > > `close(CloseMode.GRACEFUL)` respectively. Here is what I am seeing: > > > > - When the server has never been requested it shuts down instantly > > ✔️ > > - When the server has been requested by a client without keep-alive > > it > > shuts down instantly ✔️ > > - When the server has been requested by a client with keep-alive and > > the > > request is in-flight during shutdown it shuts down as soon as the > > request is done ✔️ > > > > The problem is, when I connected with a client that uses keep-alive, > > and > > the request has been handled by the server and now the client is > > holding > > the connection open, then when I shutdown the server, the server > > will > > take the whole grace period to shutdown at which point the keep- > > alive > > connections are finally being force-closed. > > > > Is it possible to somehow speed up the shutdown also in this case > > without terminating in-flight requests? Is there maybe a workaround > > to > > terminate all idle connections with keep-alives immediately before > > shutdown? > > > > The problem is there is no way of reliably testing whether a connection > is idle or not, as connections can become active immediately after > passing inactivity test. > > What could be a reasonable solution in many cases is to reduce the > default grace period timeout. > > This will make the server await connection termination for 1 second > instead of 5 seconds. > ``` > HttpServer server = ServerBootstrap.bootstrap().create(); > server.initiateShutdown(); > server.awaitTermination(TimeValue.ofSeconds(1)); > server.close(CloseMode.IMMEDIATE); > ``` > > Having said that there might be a better way to detect idle server-side > connections as well. Feel free to raise a request in JIRA if you want > me to look into that. > > Oleg > > >
Re: HttpServer on shutdown waits for entire grace period when client is connected using keep-alive
On Fri, 2020-08-07 at 20:04 +0200, Niklas Lochschmidt wrote: > I am trying to use the graceful shutdown of HttpServer server for > http4k, using HttpCore 4.4.13 and 5.0.1. I am creating the server > simply > using `ServerBootstrap.bootstrap().register(...).create()` and > shutting > down with `shutdown(5, TimeUnit.SECONDS)` and > `close(CloseMode.GRACEFUL)` respectively. Here is what I am seeing: > > - When the server has never been requested it shuts down instantly > ✔️ > - When the server has been requested by a client without keep-alive > it > shuts down instantly ✔️ > - When the server has been requested by a client with keep-alive and > the > request is in-flight during shutdown it shuts down as soon as the > request is done ✔️ > > The problem is, when I connected with a client that uses keep-alive, > and > the request has been handled by the server and now the client is > holding > the connection open, then when I shutdown the server, the server > will > take the whole grace period to shutdown at which point the keep- > alive > connections are finally being force-closed. > > Is it possible to somehow speed up the shutdown also in this case > without terminating in-flight requests? Is there maybe a workaround > to > terminate all idle connections with keep-alives immediately before > shutdown? > The problem is there is no way of reliably testing whether a connection is idle or not, as connections can become active immediately after passing inactivity test. What could be a reasonable solution in many cases is to reduce the default grace period timeout. This will make the server await connection termination for 1 second instead of 5 seconds. ``` HttpServer server = ServerBootstrap.bootstrap().create(); server.initiateShutdown(); server.awaitTermination(TimeValue.ofSeconds(1)); server.close(CloseMode.IMMEDIATE); ``` Having said that there might be a better way to detect idle server-side connections as well. Feel free to raise a request in JIRA if you want me to look into that. Oleg - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
HttpServer on shutdown waits for entire grace period when client is connected using keep-alive
I am trying to use the graceful shutdown of HttpServer server for http4k, using HttpCore 4.4.13 and 5.0.1. I am creating the server simply using `ServerBootstrap.bootstrap().register(...).create()` and shutting down with `shutdown(5, TimeUnit.SECONDS)` and `close(CloseMode.GRACEFUL)` respectively. Here is what I am seeing: - When the server has never been requested it shuts down instantly ✔️ - When the server has been requested by a client without keep-alive it shuts down instantly ✔️ - When the server has been requested by a client with keep-alive and the request is in-flight during shutdown it shuts down as soon as the request is done ✔️ The problem is, when I connected with a client that uses keep-alive, and the request has been handled by the server and now the client is holding the connection open, then when I shutdown the server, the server will take the whole grace period to shutdown at which point the keep-alive connections are finally being force-closed. Is it possible to somehow speed up the shutdown also in this case without terminating in-flight requests? Is there maybe a workaround to terminate all idle connections with keep-alives immediately before shutdown? Kind regards Niklas Lochschmidt - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Issue with Proxy / keep alive , getting NoHttpResponseException after a failed request
Hello Oleg,
Thanks for your help, I confirm it works.
So issue would be in JMeter Recorder.
Thanks
On Tue, Dec 18, 2018 at 2:53 PM Oleg Kalnichevski wrote:
> On Tue, 2018-12-18 at 14:13 +0100, Philippe Mouawad wrote:
> > Hello,
> > We face a bug in JMeter when :
> >
> >- using proxy
> >- and using POST method which leads to a 404
> >- The first request leads as expected to a 404 results
> >- BUT (bug is here) the second one triggers a
> >org.apache.http.NoHttpResponseException: jmeter.apache.org:80
> > failed to
> >respond
> >
> > Bug id:
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=63015
> >
> > To reproduce it in Junit below , I just added:
> >
> >- EntityUtils.consumeQuietly(response.getEntity());
> >
> > This call consumes data and at the end will call
> > ConnHolder#releaseConnection(true).
> > While if missing, ConnHolder#releaseConnection(false) would be called
> > closing the Connection so since we start with a new one, it's ok.
> >
> > In JMeter , since we consume data we end up calling
> > eofWatcher.eofDetected(toCheckStream);which calls
> > ResponseEntityProxy#eofDetected which calls
> > ConnHolder#releaseConnection(true);
> >
> >
> >
> > Find below JUnit:
> >
>
> JUnit passes for me. Squid proxy docker image can be found here:
>
>
> https://github.com/apache/httpcomponents-client/tree/master/httpclient5-testing/docker/squid
>
> Oleg
>
> > @Test
> > public void bugWithPostAndProxy() throws Exception {
> > PoolingHttpClientConnectionManager pHCCM = new
> > PoolingHttpClientConnectionManager(2000, TimeUnit.MILLISECONDS);
> > pHCCM.setDefaultMaxPerRoute(5);
> > pHCCM.setValidateAfterInactivity(1700);
> > HttpHost proxy = new HttpHost("localhost", , "http");
> >
> > RequestConfig config =
> > RequestConfig.custom().setProxy(proxy).build();
> >
> > try (CloseableHttpClient httpclient = HttpClients.custom().
> > setConnectionManager(pHCCM).
> > setDefaultSocketConfig(SocketConfig.DEFAULT).
> > setConnectionTimeToLive(2000, TimeUnit.MILLISECONDS).
> > setRetryHandler(new
> > StandardHttpRequestRetryHandler(0,
> > false)).
> >
> > setConnectionReuseStrategy(DefaultClientConnectionReuseStrategy.INSTA
> > NCE).
> > build()) {
> > HttpHost target = new HttpHost("jmeter.apache.org");
> > HttpPost request = new HttpPost("/404.html");
> > request.addHeader("Content-Type",
> > "application/x-www-form-urlencoded; charset=UTF-8");
> > request.addHeader("Connection", "keep-alive");
> > request.setConfig(config);
> > HttpContext httpContext = new BasicHttpContext();
> > httpContext.setAttribute(HttpClientContext.USER_TOKEN,
> > "Thread
> > Group1-1");
> > try (CloseableHttpResponse response =
> > httpclient.execute(target, request, httpContext)) {
> > logger.info("Headers:{}",
> > response.getEntity().toString());
> > EntityUtils.consumeQuietly(response.getEntity());
> > logger.info("Headers:{}", response.getAllHeaders());
> > }
> > request = new HttpPost("/404.html");
> > request.addHeader("Connection", "keep-alive");
> > try (CloseableHttpResponse response =
> > httpclient.execute(target, request, httpContext)) {
> > EntityUtils.consumeQuietly(response.getEntity());
> > logger.info("Headers:{}",
> > response.getEntity().toString());
> > logger.info("Headers:{}", response.getAllHeaders());
> > }
> > }
> > }
> >
> >
> >
> > Stacktrace:
> > org.apache.http.NoHttpResponseException: jmeter.apache.org:80 failed
> > to
> > respond
> > at
> > org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Default
> > HttpResponseParser.java:141)
> > at
> > org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Default
> > HttpResponseParser.java:56)
> > at
> > org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessagePa
> > rser.java:259)
> > at
> > org.apache.http
Re: Keep-Alive
On Mon, 2016-06-13 at 11:23 -0700, Rallavagu wrote:
>
> On 6/7/16 6:13 AM, Oleg Kalnichevski wrote:
> > On Mon, 2016-06-06 at 13:43 -0700, Rallavagu wrote:
> >> HttpClient 4.3.2, JDK 7
> >>
> >> I was doing something similar to what is talked in this link related to
> >> http commons client 3.x
> >>
> >> http://httpcomponents.10934.n7.nabble.com/quot-Keep-alive-quot-stale-connections-and-socket-reuse-td15315.html
> >>
> >> I am using PoolingHttpClientConnectionManager with following SocketConfig.
> >>
> >> SocketConfig socketConfig =
> >> SocketConfig.copy(SocketConfig.DEFAULT).setSoKeepAlive(true).setSoReuseAddress(true).build();
> >>
> >> From debug logs, I see that connections are maintained in the pool.
> >> Here is the snippet from the log.
> >>
> >> [DEBUG] 06/06/2016 12:58:16
> >> org.apache.http.impl.conn.PoolingHttpClientConnectionManager Connection
> >> request: [route: {s}->https://:443][total kept alive: 1; route
> >> allocated: 1 of 50; total allocated: 1 of 100]
> >> [DEBUG] 06/06/2016 12:58:16
> >> org.apache.http.impl.conn.PoolingHttpClientConnectionManager Connection
> >> leased: [id: 2][route: {s}->https://:443][total kept alive: 0;
> >> route allocated: 1 of 50; total allocated: 1 of 100]
> >> [DEBUG] 06/06/2016 12:58:16
> >> org.apache.http.impl.conn.PoolingHttpClientConnectionManager Connection
> >> released: [id: 2][route: {s}->https://:443][total kept alive: 1;
> >> route allocated: 1 of 50; total allocated: 1 of 100]
> >>
> >> What I am noticing is that every time a connection is used (leased) from
> >> the pool, a connection is being established (socketConnect) to the
> >> server unless requested in quick successions where a connection is
> >> detected as "not stale". Snippet from "MainClientExec.java"
> >>
> >> if (config.isStaleConnectionCheckEnabled()) {
> >> // validate connection
> >> if (managedConn.isOpen()) {
> >> this.log.debug("Stale connection check");
> >> if (managedConn.isStale()) {
> >> this.log.debug("Stale connection detected");
> >> managedConn.close();
> >> }
> >> }
> >> }
> >>
> >>
> >> Using AspectJ, I could track connection opening to the server.
> >>
> >> [INFO] 06/06/2016 12:58:00 com.test.aop.AbstractLogAspect
> >> SSLConnectionSocketFactory.java:232.connectSocket arguments [3,
> >> Socket[addr=/,port=443,localport=49439],
> >> https://:443, /:443, null,
> >> org.apache.http.client.protocol.HttpClientContext@137f7542] Execution
> >> time: 313
> >>
> >> The above call is not happening when "managedConn.isStale()" returns false.
> >>
> >> As you can see, I would like to avoid the "connectSocket" call as it is
> >> expensive. Am I right in my assumption that a "keep-alive" connection is
> >> supposed to work on an already established socket so it is being reused?
> >
> > Yes, you are.
>
> Thanks. I could validate that keep-alive connection works on already
> established socket.
> >
> >> Also, I understand that we can't rely on isStale() method. Any
> >> comments/suggestions are welcome.
> >>
> >
> > Please consider upgrading to 4.5.2. Stale connection check logic has
> > been reworked in 4.5
> I have upgraded to 4.5.2 and found that "setValidateAfterInactivity"
> method could be used to check for stale connections.
>
> I have a background thread to detect and clear idle/expired connections
> from PoolingHttpClientConnectionManager. I wonder how would
> "setValidateAfterInactivity" impact that if at all.
>
It would not (unless, of course, expiry deadline is less than inactivity
period).
> I understand that per http/1.1 spec a keep-alive request is assumed to
> be "forever" in case server does not respond with keep-alive header.
> But, connections are in fact not left open forever (in tomcat, it
> defaults to 20 sec; connectionTimeout="2"). Doesn't it make sense to
> set a response header so a client can manage keep-alive connection more
> gracefully by sending "Connection: close" when they expire? In the case
> of background thread to check expired connections, there won't be any as
> server never responded with keep-alive header and connections are marked
> to be kept alive forever. Is the only solution is to create a servlet
> filter that sets the response header?
>
Use custom ConnectionKeepAliveStrategy to set a finite keep-alive period
by default .
Oleg
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Keep-Alive
On 6/7/16 6:13 AM, Oleg Kalnichevski wrote:
On Mon, 2016-06-06 at 13:43 -0700, Rallavagu wrote:
HttpClient 4.3.2, JDK 7
I was doing something similar to what is talked in this link related to
http commons client 3.x
http://httpcomponents.10934.n7.nabble.com/quot-Keep-alive-quot-stale-connections-and-socket-reuse-td15315.html
I am using PoolingHttpClientConnectionManager with following SocketConfig.
SocketConfig socketConfig =
SocketConfig.copy(SocketConfig.DEFAULT).setSoKeepAlive(true).setSoReuseAddress(true).build();
From debug logs, I see that connections are maintained in the pool.
Here is the snippet from the log.
[DEBUG] 06/06/2016 12:58:16
org.apache.http.impl.conn.PoolingHttpClientConnectionManager Connection
request: [route: {s}->https://:443][total kept alive: 1; route
allocated: 1 of 50; total allocated: 1 of 100]
[DEBUG] 06/06/2016 12:58:16
org.apache.http.impl.conn.PoolingHttpClientConnectionManager Connection
leased: [id: 2][route: {s}->https://:443][total kept alive: 0;
route allocated: 1 of 50; total allocated: 1 of 100]
[DEBUG] 06/06/2016 12:58:16
org.apache.http.impl.conn.PoolingHttpClientConnectionManager Connection
released: [id: 2][route: {s}->https://:443][total kept alive: 1;
route allocated: 1 of 50; total allocated: 1 of 100]
What I am noticing is that every time a connection is used (leased) from
the pool, a connection is being established (socketConnect) to the
server unless requested in quick successions where a connection is
detected as "not stale". Snippet from "MainClientExec.java"
if (config.isStaleConnectionCheckEnabled()) {
// validate connection
if (managedConn.isOpen()) {
this.log.debug("Stale connection check");
if (managedConn.isStale()) {
this.log.debug("Stale connection detected");
managedConn.close();
}
}
}
Using AspectJ, I could track connection opening to the server.
[INFO] 06/06/2016 12:58:00 com.test.aop.AbstractLogAspect
SSLConnectionSocketFactory.java:232.connectSocket arguments [3,
Socket[addr=/,port=443,localport=49439],
https://:443, /:443, null,
org.apache.http.client.protocol.HttpClientContext@137f7542] Execution
time: 313
The above call is not happening when "managedConn.isStale()" returns false.
As you can see, I would like to avoid the "connectSocket" call as it is
expensive. Am I right in my assumption that a "keep-alive" connection is
supposed to work on an already established socket so it is being reused?
Yes, you are.
Thanks. I could validate that keep-alive connection works on already
established socket.
Also, I understand that we can't rely on isStale() method. Any
comments/suggestions are welcome.
Please consider upgrading to 4.5.2. Stale connection check logic has
been reworked in 4.5
I have upgraded to 4.5.2 and found that "setValidateAfterInactivity"
method could be used to check for stale connections.
I have a background thread to detect and clear idle/expired connections
from PoolingHttpClientConnectionManager. I wonder how would
"setValidateAfterInactivity" impact that if at all.
I understand that per http/1.1 spec a keep-alive request is assumed to
be "forever" in case server does not respond with keep-alive header.
But, connections are in fact not left open forever (in tomcat, it
defaults to 20 sec; connectionTimeout="2"). Doesn't it make sense to
set a response header so a client can manage keep-alive connection more
gracefully by sending "Connection: close" when they expire? In the case
of background thread to check expired connections, there won't be any as
server never responded with keep-alive header and connections are marked
to be kept alive forever. Is the only solution is to create a servlet
filter that sets the response header?
Thanks
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: Keep-Alive
On Mon, 2016-06-06 at 13:43 -0700, Rallavagu wrote:
> HttpClient 4.3.2, JDK 7
>
> I was doing something similar to what is talked in this link related to
> http commons client 3.x
>
> http://httpcomponents.10934.n7.nabble.com/quot-Keep-alive-quot-stale-connections-and-socket-reuse-td15315.html
>
> I am using PoolingHttpClientConnectionManager with following SocketConfig.
>
> SocketConfig socketConfig =
> SocketConfig.copy(SocketConfig.DEFAULT).setSoKeepAlive(true).setSoReuseAddress(true).build();
>
> From debug logs, I see that connections are maintained in the pool.
> Here is the snippet from the log.
>
> [DEBUG] 06/06/2016 12:58:16
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager Connection
> request: [route: {s}->https://:443][total kept alive: 1; route
> allocated: 1 of 50; total allocated: 1 of 100]
> [DEBUG] 06/06/2016 12:58:16
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager Connection
> leased: [id: 2][route: {s}->https://:443][total kept alive: 0;
> route allocated: 1 of 50; total allocated: 1 of 100]
> [DEBUG] 06/06/2016 12:58:16
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager Connection
> released: [id: 2][route: {s}->https://:443][total kept alive: 1;
> route allocated: 1 of 50; total allocated: 1 of 100]
>
> What I am noticing is that every time a connection is used (leased) from
> the pool, a connection is being established (socketConnect) to the
> server unless requested in quick successions where a connection is
> detected as "not stale". Snippet from "MainClientExec.java"
>
> if (config.isStaleConnectionCheckEnabled()) {
> // validate connection
> if (managedConn.isOpen()) {
> this.log.debug("Stale connection check");
> if (managedConn.isStale()) {
> this.log.debug("Stale connection detected");
> managedConn.close();
> }
> }
> }
>
>
> Using AspectJ, I could track connection opening to the server.
>
> [INFO] 06/06/2016 12:58:00 com.test.aop.AbstractLogAspect
> SSLConnectionSocketFactory.java:232.connectSocket arguments [3,
> Socket[addr=/,port=443,localport=49439],
> https://:443, /:443, null,
> org.apache.http.client.protocol.HttpClientContext@137f7542] Execution
> time: 313
>
> The above call is not happening when "managedConn.isStale()" returns false.
>
> As you can see, I would like to avoid the "connectSocket" call as it is
> expensive. Am I right in my assumption that a "keep-alive" connection is
> supposed to work on an already established socket so it is being reused?
Yes, you are.
> Also, I understand that we can't rely on isStale() method. Any
> comments/suggestions are welcome.
>
Please consider upgrading to 4.5.2. Stale connection check logic has
been reworked in 4.5
Oleg
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Keep-Alive
HttpClient 4.3.2, JDK 7
I was doing something similar to what is talked in this link related to
http commons client 3.x
http://httpcomponents.10934.n7.nabble.com/quot-Keep-alive-quot-stale-connections-and-socket-reuse-td15315.html
I am using PoolingHttpClientConnectionManager with following SocketConfig.
SocketConfig socketConfig =
SocketConfig.copy(SocketConfig.DEFAULT).setSoKeepAlive(true).setSoReuseAddress(true).build();
From debug logs, I see that connections are maintained in the pool.
Here is the snippet from the log.
[DEBUG] 06/06/2016 12:58:16
org.apache.http.impl.conn.PoolingHttpClientConnectionManager Connection
request: [route: {s}->https://:443][total kept alive: 1; route
allocated: 1 of 50; total allocated: 1 of 100]
[DEBUG] 06/06/2016 12:58:16
org.apache.http.impl.conn.PoolingHttpClientConnectionManager Connection
leased: [id: 2][route: {s}->https://:443][total kept alive: 0;
route allocated: 1 of 50; total allocated: 1 of 100]
[DEBUG] 06/06/2016 12:58:16
org.apache.http.impl.conn.PoolingHttpClientConnectionManager Connection
released: [id: 2][route: {s}->https://:443][total kept alive: 1;
route allocated: 1 of 50; total allocated: 1 of 100]
What I am noticing is that every time a connection is used (leased) from
the pool, a connection is being established (socketConnect) to the
server unless requested in quick successions where a connection is
detected as "not stale". Snippet from "MainClientExec.java"
if (config.isStaleConnectionCheckEnabled()) {
// validate connection
if (managedConn.isOpen()) {
this.log.debug("Stale connection check");
if (managedConn.isStale()) {
this.log.debug("Stale connection detected");
managedConn.close();
}
}
}
Using AspectJ, I could track connection opening to the server.
[INFO] 06/06/2016 12:58:00 com.test.aop.AbstractLogAspect
SSLConnectionSocketFactory.java:232.connectSocket arguments [3,
Socket[addr=/,port=443,localport=49439],
https://:443, /:443, null,
org.apache.http.client.protocol.HttpClientContext@137f7542] Execution
time: 313
The above call is not happening when "managedConn.isStale()" returns false.
As you can see, I would like to avoid the "connectSocket" call as it is
expensive. Am I right in my assumption that a "keep-alive" connection is
supposed to work on an already established socket so it is being reused?
Also, I understand that we can't rely on isStale() method. Any
comments/suggestions are welcome.
Thanks in advance.
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Apache HttpClient TCP Keep-Alive (socket keep-alive)
> How do you know the keepalive packets have not been sent? Did you run a tcpdump? I used Wireshark with "tcp.analysis.keep_alive || tcp.analysis.keep_alive_ack" filter to monitor connection between client and server. > The socket API (java and apache) traditionally does not support to configure the keepalive times, they only allow to turn it on. Yes. As I know the only way to set those timeouts is configuring Linux parameters. By default keep-alive timeout is 2 hours which is too long :) Some explanations: http://stackoverflow.com/questions/1480236/does-a-tcp-socket-connection-have-a-keep-alive/33927447#33927447 Thanks, Baratali Izmailov. On 18 May 2016 at 20:19, <e...@zusammenkunft.net> wrote: > How do you know the keepalive packets have not been sent? Did you run a > tcpdump? > > The socket API (java and apache) traditionally does not support to > configure the keepalive times, they only allow to turn it on. > > BTW: still think tcp keepalives are not what you want to rely on and might > not help to keep a connection open if an intermediate wants to be an > annoyance. > > Greetings > Bernd > > -- > http://bernd.eckenfels.net > > -Original Message- > From: Baratali Izmailov <baratal...@gmail.com> > To: HttpClient User Discussion <httpclient-users@hc.apache.org> > Sent: Mi., 18 Mai 2016 12:37 > Subject: Re: Apache HttpClient TCP Keep-Alive (socket keep-alive) > > Thank you. I updated Apache HttpClient version as you described. However, > it didn't help, TCP KeepAlive packets were not sent between client and > server. > If correctly understand, the problem is that I cannot edit TCP KeepAlive > timouts in HttpClient or even in Apache httpd server. It works only if I > set timeouts on OS level (in Linux): > sudo sysctl -w net.ipv4.tcp_keepalive_time=60 > sudo sysctl -w net.ipv4.tcp_keepalive_intvl=60 > sudo sysctl -w net.ipv4.tcp_keepalive_probes=10 > > With such configs the server sends TCP KeepAlive packets every 60 seconds. > > Thanks, > Baratali Izmailov. > > On 12 May 2016 at 15:53, Oleg Kalnichevski <ol...@apache.org> wrote: > > > On Thu, 2016-05-12 at 13:46 +0100, Baratali Izmailov wrote: > > > > Please consider upgrading. I am not entirely sure if HC 4.2 supports > > TCP keepalive > > > setting. > > > > > > Unfortunately, to upgrade HC we need to upgrade Spring to the latest > > > version which requires Java 8. But, we cannot force our clients to use > > Java > > > 8 yet. > > > > There is no need to upgrade Spring. You can upgrade HC dependency to > > something more recent without upgrading Spring itself. > > > > In this case however you should pass a custom instance of HttpClient to > > ClientHttpRequestFactory > > > > > > > https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/http/client/HttpComponentsClientHttpRequestFactory.html#HttpComponentsClientHttpRequestFactory-org.apache.http.client.HttpClient- > > > > > However, I don't see SO_KEEPALIVE parameter in the lastest Apache HC > > > javadocs in "The following parameters can be used to customize the > > behavior > > > of this class:" section: > > > > > > https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpClient.html > > > > > > Could you please show me example how to set SO_KEEPALIVE parameter in > new > > > versions of Apache HC? > > > > > > > --- > > SocketConfig socketConfig = SocketConfig.custom() > > .setSoKeepAlive(true) > > .build(); > > CloseableHttpClient client = HttpClientBuilder.create() > > .setDefaultSocketConfig(socketConfig) > > .build(); > > ClientHttpRequestFactory clientfactory = new > > HttpComponentsClientHttpRequestFactory(client); > > --- > > > > Hope this helps > > > > Oleg > > > > > > > Thanks, > > > Baratali Izmailov. > > > > > > On 12 May 2016 at 09:53, Oleg Kalnichevski <ol...@apache.org> wrote: > > > > > > > On Thu, 2016-05-12 at 09:23 +0100, Baratali Izmailov wrote: > > > > > Hello. Thanks for the quick response. > > > > > > > > > > > Is there any way you can turn this into 2 requests? > > > > > For now we cannot split this into 2 HTTP requests, because we have > to > > > > > change client-server protocol communication and re-implement some > > parts > > > > of > > > > > our application, which will take much time. > > > > &
Re: Apache HttpClient TCP Keep-Alive (socket keep-alive)
How do you know the keepalive packets have not been sent? Did you run a tcpdump? The socket API (java and apache) traditionally does not support to configure the keepalive times, they only allow to turn it on. BTW: still think tcp keepalives are not what you want to rely on and might not help to keep a connection open if an intermediate wants to be an annoyance. Greetings Bernd -- http://bernd.eckenfels.net -Original Message- From: Baratali Izmailov <baratal...@gmail.com> To: HttpClient User Discussion <httpclient-users@hc.apache.org> Sent: Mi., 18 Mai 2016 12:37 Subject: Re: Apache HttpClient TCP Keep-Alive (socket keep-alive) Thank you. I updated Apache HttpClient version as you described. However, it didn't help, TCP KeepAlive packets were not sent between client and server. If correctly understand, the problem is that I cannot edit TCP KeepAlive timouts in HttpClient or even in Apache httpd server. It works only if I set timeouts on OS level (in Linux): sudo sysctl -w net.ipv4.tcp_keepalive_time=60 sudo sysctl -w net.ipv4.tcp_keepalive_intvl=60 sudo sysctl -w net.ipv4.tcp_keepalive_probes=10 With such configs the server sends TCP KeepAlive packets every 60 seconds. Thanks, Baratali Izmailov. On 12 May 2016 at 15:53, Oleg Kalnichevski <ol...@apache.org> wrote: > On Thu, 2016-05-12 at 13:46 +0100, Baratali Izmailov wrote: > > > Please consider upgrading. I am not entirely sure if HC 4.2 supports > TCP keepalive > > setting. > > > > Unfortunately, to upgrade HC we need to upgrade Spring to the latest > > version which requires Java 8. But, we cannot force our clients to use > Java > > 8 yet. > > There is no need to upgrade Spring. You can upgrade HC dependency to > something more recent without upgrading Spring itself. > > In this case however you should pass a custom instance of HttpClient to > ClientHttpRequestFactory > > > https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/http/client/HttpComponentsClientHttpRequestFactory.html#HttpComponentsClientHttpRequestFactory-org.apache.http.client.HttpClient- > > > However, I don't see SO_KEEPALIVE parameter in the lastest Apache HC > > javadocs in "The following parameters can be used to customize the > behavior > > of this class:" section: > > > https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpClient.html > > > > Could you please show me example how to set SO_KEEPALIVE parameter in new > > versions of Apache HC? > > > > --- > SocketConfig socketConfig = SocketConfig.custom() > .setSoKeepAlive(true) > .build(); > CloseableHttpClient client = HttpClientBuilder.create() > .setDefaultSocketConfig(socketConfig) > .build(); > ClientHttpRequestFactory clientfactory = new > HttpComponentsClientHttpRequestFactory(client); > --- > > Hope this helps > > Oleg > > > > Thanks, > > Baratali Izmailov. > > > > On 12 May 2016 at 09:53, Oleg Kalnichevski <ol...@apache.org> wrote: > > > > > On Thu, 2016-05-12 at 09:23 +0100, Baratali Izmailov wrote: > > > > Hello. Thanks for the quick response. > > > > > > > > > Is there any way you can turn this into 2 requests? > > > > For now we cannot split this into 2 HTTP requests, because we have to > > > > change client-server protocol communication and re-implement some > parts > > > of > > > > our application, which will take much time. > > > > I understand that it is not that effective to keep connection open > too > > > > long, but it's only simple solution I see for now. > > > > > > > > > What version of HttpClient are you using? It looks like something > > > fairly > > > > old. > > > > It is 4.2.2. Actually I use Spring 3.2.1 httpInvoker which uses > > > > DefaultHttpClient. > > > > > > > > > > Please consider upgrading. I am not entirely sure if HC 4.2 supports > TCP > > > keepalive setting. > > > > > > Oleg > > > > > > > > Using TCP keepalive wont help you with default OS settings, it > would > > > not > > > > start to send them in the first 20 idle minutes. > > > > Can I configure Apache httpd server to do this (set keep-alive > timeouts)? > > > > > > > > Thanks, > > > > Baratali. > > > > > > > > > > > > --------- > > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > > >
Re: Apache HttpClient TCP Keep-Alive (socket keep-alive)
Thank you. I updated Apache HttpClient version as you described. However, it didn't help, TCP KeepAlive packets were not sent between client and server. If correctly understand, the problem is that I cannot edit TCP KeepAlive timouts in HttpClient or even in Apache httpd server. It works only if I set timeouts on OS level (in Linux): sudo sysctl -w net.ipv4.tcp_keepalive_time=60 sudo sysctl -w net.ipv4.tcp_keepalive_intvl=60 sudo sysctl -w net.ipv4.tcp_keepalive_probes=10 With such configs the server sends TCP KeepAlive packets every 60 seconds. Thanks, Baratali Izmailov. On 12 May 2016 at 15:53, Oleg Kalnichevski <ol...@apache.org> wrote: > On Thu, 2016-05-12 at 13:46 +0100, Baratali Izmailov wrote: > > > Please consider upgrading. I am not entirely sure if HC 4.2 supports > TCP keepalive > > setting. > > > > Unfortunately, to upgrade HC we need to upgrade Spring to the latest > > version which requires Java 8. But, we cannot force our clients to use > Java > > 8 yet. > > There is no need to upgrade Spring. You can upgrade HC dependency to > something more recent without upgrading Spring itself. > > In this case however you should pass a custom instance of HttpClient to > ClientHttpRequestFactory > > > https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/http/client/HttpComponentsClientHttpRequestFactory.html#HttpComponentsClientHttpRequestFactory-org.apache.http.client.HttpClient- > > > However, I don't see SO_KEEPALIVE parameter in the lastest Apache HC > > javadocs in "The following parameters can be used to customize the > behavior > > of this class:" section: > > > https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpClient.html > > > > Could you please show me example how to set SO_KEEPALIVE parameter in new > > versions of Apache HC? > > > > --- > SocketConfig socketConfig = SocketConfig.custom() > .setSoKeepAlive(true) > .build(); > CloseableHttpClient client = HttpClientBuilder.create() > .setDefaultSocketConfig(socketConfig) > .build(); > ClientHttpRequestFactory clientfactory = new > HttpComponentsClientHttpRequestFactory(client); > --- > > Hope this helps > > Oleg > > > > Thanks, > > Baratali Izmailov. > > > > On 12 May 2016 at 09:53, Oleg Kalnichevski <ol...@apache.org> wrote: > > > > > On Thu, 2016-05-12 at 09:23 +0100, Baratali Izmailov wrote: > > > > Hello. Thanks for the quick response. > > > > > > > > > Is there any way you can turn this into 2 requests? > > > > For now we cannot split this into 2 HTTP requests, because we have to > > > > change client-server protocol communication and re-implement some > parts > > > of > > > > our application, which will take much time. > > > > I understand that it is not that effective to keep connection open > too > > > > long, but it's only simple solution I see for now. > > > > > > > > > What version of HttpClient are you using? It looks like something > > > fairly > > > > old. > > > > It is 4.2.2. Actually I use Spring 3.2.1 httpInvoker which uses > > > > DefaultHttpClient. > > > > > > > > > > Please consider upgrading. I am not entirely sure if HC 4.2 supports > TCP > > > keepalive setting. > > > > > > Oleg > > > > > > > > Using TCP keepalive wont help you with default OS settings, it > would > > > not > > > > start to send them in the first 20 idle minutes. > > > > Can I configure Apache httpd server to do this (set keep-alive > timeouts)? > > > > > > > > Thanks, > > > > Baratali. > > > > > > > > > > > > - > > > 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: Apache HttpClient TCP Keep-Alive (socket keep-alive)
On Thu, 2016-05-12 at 13:46 +0100, Baratali Izmailov wrote: > > Please consider upgrading. I am not entirely sure if HC 4.2 supports TCP > > keepalive > setting. > > Unfortunately, to upgrade HC we need to upgrade Spring to the latest > version which requires Java 8. But, we cannot force our clients to use Java > 8 yet. There is no need to upgrade Spring. You can upgrade HC dependency to something more recent without upgrading Spring itself. In this case however you should pass a custom instance of HttpClient to ClientHttpRequestFactory https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/http/client/HttpComponentsClientHttpRequestFactory.html#HttpComponentsClientHttpRequestFactory-org.apache.http.client.HttpClient- > However, I don't see SO_KEEPALIVE parameter in the lastest Apache HC > javadocs in "The following parameters can be used to customize the behavior > of this class:" section: > https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpClient.html > > Could you please show me example how to set SO_KEEPALIVE parameter in new > versions of Apache HC? > --- SocketConfig socketConfig = SocketConfig.custom() .setSoKeepAlive(true) .build(); CloseableHttpClient client = HttpClientBuilder.create() .setDefaultSocketConfig(socketConfig) .build(); ClientHttpRequestFactory clientfactory = new HttpComponentsClientHttpRequestFactory(client); --- Hope this helps Oleg > Thanks, > Baratali Izmailov. > > On 12 May 2016 at 09:53, Oleg Kalnichevski <ol...@apache.org> wrote: > > > On Thu, 2016-05-12 at 09:23 +0100, Baratali Izmailov wrote: > > > Hello. Thanks for the quick response. > > > > > > > Is there any way you can turn this into 2 requests? > > > For now we cannot split this into 2 HTTP requests, because we have to > > > change client-server protocol communication and re-implement some parts > > of > > > our application, which will take much time. > > > I understand that it is not that effective to keep connection open too > > > long, but it's only simple solution I see for now. > > > > > > > What version of HttpClient are you using? It looks like something > > fairly > > > old. > > > It is 4.2.2. Actually I use Spring 3.2.1 httpInvoker which uses > > > DefaultHttpClient. > > > > > > > Please consider upgrading. I am not entirely sure if HC 4.2 supports TCP > > keepalive setting. > > > > Oleg > > > > > > Using TCP keepalive wont help you with default OS settings, it would > > not > > > start to send them in the first 20 idle minutes. > > > Can I configure Apache httpd server to do this (set keep-alive timeouts)? > > > > > > Thanks, > > > Baratali. > > > > > > > > - > > 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: Apache HttpClient TCP Keep-Alive (socket keep-alive)
> Please consider upgrading. I am not entirely sure if HC 4.2 supports TCP > keepalive setting. Unfortunately, to upgrade HC we need to upgrade Spring to the latest version which requires Java 8. But, we cannot force our clients to use Java 8 yet. However, I don't see SO_KEEPALIVE parameter in the lastest Apache HC javadocs in "The following parameters can be used to customize the behavior of this class:" section: https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpClient.html Could you please show me example how to set SO_KEEPALIVE parameter in new versions of Apache HC? Thanks, Baratali Izmailov. On 12 May 2016 at 09:53, Oleg Kalnichevski <ol...@apache.org> wrote: > On Thu, 2016-05-12 at 09:23 +0100, Baratali Izmailov wrote: > > Hello. Thanks for the quick response. > > > > > Is there any way you can turn this into 2 requests? > > For now we cannot split this into 2 HTTP requests, because we have to > > change client-server protocol communication and re-implement some parts > of > > our application, which will take much time. > > I understand that it is not that effective to keep connection open too > > long, but it's only simple solution I see for now. > > > > > What version of HttpClient are you using? It looks like something > fairly > > old. > > It is 4.2.2. Actually I use Spring 3.2.1 httpInvoker which uses > > DefaultHttpClient. > > > > Please consider upgrading. I am not entirely sure if HC 4.2 supports TCP > keepalive setting. > > Oleg > > > > Using TCP keepalive wont help you with default OS settings, it would > not > > start to send them in the first 20 idle minutes. > > Can I configure Apache httpd server to do this (set keep-alive timeouts)? > > > > Thanks, > > Baratali. > > > > - > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > >
Re: Apache HttpClient TCP Keep-Alive (socket keep-alive)
On Thu, 2016-05-12 at 09:23 +0100, Baratali Izmailov wrote: > Hello. Thanks for the quick response. > > > Is there any way you can turn this into 2 requests? > For now we cannot split this into 2 HTTP requests, because we have to > change client-server protocol communication and re-implement some parts of > our application, which will take much time. > I understand that it is not that effective to keep connection open too > long, but it's only simple solution I see for now. > > > What version of HttpClient are you using? It looks like something fairly > old. > It is 4.2.2. Actually I use Spring 3.2.1 httpInvoker which uses > DefaultHttpClient. > Please consider upgrading. I am not entirely sure if HC 4.2 supports TCP keepalive setting. Oleg > > Using TCP keepalive wont help you with default OS settings, it would not > start to send them in the first 20 idle minutes. > Can I configure Apache httpd server to do this (set keep-alive timeouts)? > > Thanks, > Baratali. - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Apache HttpClient TCP Keep-Alive (socket keep-alive)
Hello. Thanks for the quick response. > Is there any way you can turn this into 2 requests? For now we cannot split this into 2 HTTP requests, because we have to change client-server protocol communication and re-implement some parts of our application, which will take much time. I understand that it is not that effective to keep connection open too long, but it's only simple solution I see for now. > What version of HttpClient are you using? It looks like something fairly old. It is 4.2.2. Actually I use Spring 3.2.1 httpInvoker which uses DefaultHttpClient. > Using TCP keepalive wont help you with default OS settings, it would not start to send them in the first 20 idle minutes. Can I configure Apache httpd server to do this (set keep-alive timeouts)? Thanks, Baratali.
Re: Apache HttpClient TCP Keep-Alive (socket keep-alive)
Hello, Using TCP keepalive wont help you with default OS settings, it would not start to send them in the first 20 idle minutes. You could configure the host to do it quicker but its not something you can portably configure from Java. Besides not all statefull filters honor it as beeing non-idle. An alternative would be to send 0-byte HTTP (content transfer) chunks from the server. Gruss Bernd -- http://bernd.eckenfels.net -Original Message- From: Oleg Kalnichevski <ol...@apache.org> To: HttpClient User Discussion <httpclient-users@hc.apache.org> Sent: Mi., 11 Mai 2016 18:46 Subject: Re: Apache HttpClient TCP Keep-Alive (socket keep-alive) On Wed, 2016-05-11 at 15:52 +0100, Baratali Izmailov wrote: > Hello, > > I have http request that takes too much time to be processed by the server > (about 5 minutes). Because connection becomes idle for 5 minutes, proxy > server shutdowns the connection. I'm trying to use TCP Keep-Alive in Apache > DefaultHttpClient to make connection be alive for a long time (Not confuse > TCP Keep-Alive with HTTP Keep-Alive that simply doesn't closes connection > after response is sent). > > Apache http core has following parameter SO_KEEPALIVE: > http://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/params/CoreConnectionPNames.html#SO_KEEPALIVE. > However, due to DefaultHttpClient javadocs I can't customize client's > behavior with that parameter: > https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpClient.html > . > > Do you know how to make DefaultHttpClient use TCP Keep-Alive strategy? > > > Thanks, > > Baratali. Baratali What version of HttpClient are you using? It looks like something fairly old. 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: Apache HttpClient TCP Keep-Alive (socket keep-alive)
On Wed, 2016-05-11 at 15:52 +0100, Baratali Izmailov wrote: > Hello, > > I have http request that takes too much time to be processed by the server > (about 5 minutes). Because connection becomes idle for 5 minutes, proxy > server shutdowns the connection. I'm trying to use TCP Keep-Alive in Apache > DefaultHttpClient to make connection be alive for a long time (Not confuse > TCP Keep-Alive with HTTP Keep-Alive that simply doesn't closes connection > after response is sent). > > Apache http core has following parameter SO_KEEPALIVE: > http://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/params/CoreConnectionPNames.html#SO_KEEPALIVE. > However, due to DefaultHttpClient javadocs I can't customize client's > behavior with that parameter: > https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpClient.html > . > > Do you know how to make DefaultHttpClient use TCP Keep-Alive strategy? > > > Thanks, > > Baratali. Baratali What version of HttpClient are you using? It looks like something fairly old. Oleg - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Apache HttpClient TCP Keep-Alive (socket keep-alive)
Is there any way you can turn this into 2 requests? 1 to kick off the long process which stores the results somewhere, and 1 to poll for the results to get them when they're available? On Wed, May 11, 2016 at 10:52 AM, Baratali Izmailov <baratal...@gmail.com> wrote: > Hello, > > I have http request that takes too much time to be processed by the server > (about 5 minutes). Because connection becomes idle for 5 minutes, proxy > server shutdowns the connection. I'm trying to use TCP Keep-Alive in Apache > DefaultHttpClient to make connection be alive for a long time (Not confuse > TCP Keep-Alive with HTTP Keep-Alive that simply doesn't closes connection > after response is sent). > > Apache http core has following parameter SO_KEEPALIVE: > > http://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/params/CoreConnectionPNames.html#SO_KEEPALIVE > . > However, due to DefaultHttpClient javadocs I can't customize client's > behavior with that parameter: > > https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpClient.html > . > > Do you know how to make DefaultHttpClient use TCP Keep-Alive strategy? > > > Thanks, > > Baratali. > -- _ *Daniel Quaroni* *Principal Software Architect* <http://invoke.com/> *office *781.810.2743 *mobile* 617.838.3147 q...@invoke.com
Apache HttpClient TCP Keep-Alive (socket keep-alive)
Hello, I have http request that takes too much time to be processed by the server (about 5 minutes). Because connection becomes idle for 5 minutes, proxy server shutdowns the connection. I'm trying to use TCP Keep-Alive in Apache DefaultHttpClient to make connection be alive for a long time (Not confuse TCP Keep-Alive with HTTP Keep-Alive that simply doesn't closes connection after response is sent). Apache http core has following parameter SO_KEEPALIVE: http://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/params/CoreConnectionPNames.html#SO_KEEPALIVE. However, due to DefaultHttpClient javadocs I can't customize client's behavior with that parameter: https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpClient.html . Do you know how to make DefaultHttpClient use TCP Keep-Alive strategy? Thanks, Baratali.
Keep alive
Hello,
After migrating to 4.3 from 4.1, I dont get keep-alive connections working.
My code is:
(
)
if (this.vkas == null) this.vkas = new KeepAliveStrategy(keepAliveDuration);
else this.vkas.setKeepAliveDuration(keepAliveDuration);
(...)
HttpClientBuilder hcBuilder =
HttpClients.custom().setConnectionManager(this.phccm).
disableCookieManagement().
setDefaultRequestConfig(this.rc).
setRetryHandler(this.rrh).
setKeepAliveStrategy(this.vkas);
// Add proxy.
if (proxyPort 0) hcBuilder.setProxy(new HttpHost(proxyHost, proxyPort));
// Build 'HttpClient'.
this.objHttp = hcBuilder.build();
When I send a request, http log shows the following (with a keep alive of 20
seconds):
Auth cache not set in the context
Connection request: [route: {}-http://ws.rhodasol.es:80][total kept alive:
0; route allocated: 0 of 100; total allocated: 0 of 100]
Connection leased: [id: 148][route: {}-http://ws.rhodasol.es:80][total kept
alive: 0; route allocated: 1 of 100; total allocated: 1 of 100]
Connecting to ws.rhodasol.es/188.165.133.226:80
http-outgoing-148: Shutdown connection
http-outgoing-148: Close connection
Connection released: [id: 148][route: {}-http://ws.rhodasol.es:80][total
kept alive: 0; route allocated: 0 of 100; total allocated: 0 of 100]
In fact, my KeepAliveStrategy class is not called, because none of the
traces I put there are logged.
Should I enable keep alive in any way before calling the
setKeepAliveStrategy method?
Thanks,
Joan.
RE: Keep alive
Hello,
Forget it ...
Thanks.
Joan.
-Mensaje original-
De: Joan Balagueró [mailto:joan.balagu...@grupoventus.com]
Enviado el: jueves, 13 de marzo de 2014 19:23
Para: httpclient-users@hc.apache.org
Asunto: Keep alive
Hello,
After migrating to 4.3 from 4.1, I dont get keep-alive connections working.
My code is:
(
)
if (this.vkas == null) this.vkas = new KeepAliveStrategy(keepAliveDuration);
else this.vkas.setKeepAliveDuration(keepAliveDuration);
(...)
HttpClientBuilder hcBuilder =
HttpClients.custom().setConnectionManager(this.phccm).
disableCookieManagement().
setDefaultRequestConfig(this.rc).
setRetryHandler(this.rrh).
setKeepAliveStrategy(this.vkas);
// Add proxy.
if (proxyPort 0) hcBuilder.setProxy(new HttpHost(proxyHost, proxyPort));
// Build 'HttpClient'.
this.objHttp = hcBuilder.build();
When I send a request, http log shows the following (with a keep alive of 20
seconds):
Auth cache not set in the context
Connection request: [route: {}-http://ws.rhodasol.es:80][total kept alive:
0; route allocated: 0 of 100; total allocated: 0 of 100]
Connection leased: [id: 148][route: {}-http://ws.rhodasol.es:80][total kept
alive: 0; route allocated: 1 of 100; total allocated: 1 of 100]
Connecting to ws.rhodasol.es/188.165.133.226:80
http-outgoing-148: Shutdown connection
http-outgoing-148: Close connection
Connection released: [id: 148][route: {}-http://ws.rhodasol.es:80][total
kept alive: 0; route allocated: 0 of 100; total allocated: 0 of 100]
In fact, my KeepAliveStrategy class is not called, because none of the
traces I put there are logged.
Should I enable keep alive in any way before calling the
setKeepAliveStrategy method?
Thanks,
Joan.
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Keep alive
You can use IdleConnectionTimeoutThread for the same :) On Fri, Apr 1, 2011 at 12:41 AM, Vadheraju, Rajeshwar rajeshwar.vadher...@fisglobal.com wrote: Yes, agreed. I think it is good idea to implement retry and idle connection handler as opposed to keep alive strategy. How did you implement or use idle connection thread? I am using xfire as my soap framework which uses MultiThreadedConnectionManager internally, not sure how to tell xfire to use or run IdleConenction Thread? -Original Message- From: Joan Balaguero [mailto:joan.balagu...@grupoventus.com] Sent: Thursday, March 31, 2011 12:50 PM To: Vadheraju, Rajeshwar Cc: 'HttpClient User Discussion' Subject: RE: Keep alive Hi Raj, In my case, I'm sending requests to problematic servers. By problematic I mean that they're abruptly closing the http sockets. That's why I'm not interested in keeping alive my http connections for so many time, because after few seconds (~10 seconds), they will be probably closed on the server side. In addition, it's also a good idea to implement an IdleConnection Handler to manage idle connections (and, in the same method, also call to 'closeExpiredConnections', recommendation made by Oleg to me some months ago) and also a 'Retry' handler. With this combination of strategies, you will minimize connection problems (like a 'Connection reset'), but you don't have to expect to solve the problems completely. Using Http protocol, you ALWAYS will lose requests due to connection problems. Regards, Joan. -Mensaje original- De: Vadheraju, Rajeshwar [mailto:rajeshwar.vadher...@fisglobal.com] Enviado el: jueves, 31 de marzo de 2011 18:19 Para: HttpClient User Discussion Asunto: RE: Keep alive Hi Joan, I'm also researching on the same area. Could you please provide some details why you are implementing keep alive strategy? In other words, What problems prompted you to implement keep alive strategy? If you could elaborate on your issue, I could share some of my experience and research findings. Thanks, Raj -Original Message- From: Joan Balaguero [mailto:joan.balagu...@grupoventus.com] Sent: Thursday, March 31, 2011 11:13 AM To: 'HttpClient User Discussion' Subject: Keep alive Hello Oleg, I've implemented a Connection Keep Alive strategy in my app, but I'm not able to see what is the better way to check if it's working ok. Could you give any clue about how to do this? Thanks, Joan. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
RE: Keep alive
Hi Gurmeet, The MultiThreadedConenctionManager is invoked/created by Xfire Client, then how would I indicate Xfire Client to use/invoke IdleConnectionTimeoutThread? -Original Message- From: Gurmeet Budhraja [mailto:guri.mailingli...@gmail.com] Sent: Friday, April 01, 2011 6:44 AM To: HttpClient User Discussion Subject: Re: Keep alive You can use IdleConnectionTimeoutThread for the same :) On Fri, Apr 1, 2011 at 12:41 AM, Vadheraju, Rajeshwar rajeshwar.vadher...@fisglobal.com wrote: Yes, agreed. I think it is good idea to implement retry and idle connection handler as opposed to keep alive strategy. How did you implement or use idle connection thread? I am using xfire as my soap framework which uses MultiThreadedConnectionManager internally, not sure how to tell xfire to use or run IdleConenction Thread? -Original Message- From: Joan Balaguero [mailto:joan.balagu...@grupoventus.com] Sent: Thursday, March 31, 2011 12:50 PM To: Vadheraju, Rajeshwar Cc: 'HttpClient User Discussion' Subject: RE: Keep alive Hi Raj, In my case, I'm sending requests to problematic servers. By problematic I mean that they're abruptly closing the http sockets. That's why I'm not interested in keeping alive my http connections for so many time, because after few seconds (~10 seconds), they will be probably closed on the server side. In addition, it's also a good idea to implement an IdleConnection Handler to manage idle connections (and, in the same method, also call to 'closeExpiredConnections', recommendation made by Oleg to me some months ago) and also a 'Retry' handler. With this combination of strategies, you will minimize connection problems (like a 'Connection reset'), but you don't have to expect to solve the problems completely. Using Http protocol, you ALWAYS will lose requests due to connection problems. Regards, Joan. -Mensaje original- De: Vadheraju, Rajeshwar [mailto:rajeshwar.vadher...@fisglobal.com] Enviado el: jueves, 31 de marzo de 2011 18:19 Para: HttpClient User Discussion Asunto: RE: Keep alive Hi Joan, I'm also researching on the same area. Could you please provide some details why you are implementing keep alive strategy? In other words, What problems prompted you to implement keep alive strategy? If you could elaborate on your issue, I could share some of my experience and research findings. Thanks, Raj -Original Message- From: Joan Balaguero [mailto:joan.balagu...@grupoventus.com] Sent: Thursday, March 31, 2011 11:13 AM To: 'HttpClient User Discussion' Subject: Keep alive Hello Oleg, I've implemented a Connection Keep Alive strategy in my app, but I'm not able to see what is the better way to check if it's working ok. Could you give any clue about how to do this? Thanks, Joan. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Keep alive
You can increase the logging level as per the Enable context logging for connection management / request execution instructions listed on http://hc.apache.org/httpcomponents-client-ga/logging.html Alternatively, you could use tcpdump or Wireshark to capture the packets and see if the same TCP connection is being re-used. Thanks, Sam On 31 March 2011 17:12, Joan Balaguero joan.balagu...@grupoventus.com wrote: Hello Oleg, I’ve implemented a Connection Keep Alive strategy in my app, but I’m not able to see what is the better way to check if it’s working ok. Could you give any clue about how to do this? Thanks, Joan. - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
RE: Keep alive
Hi Joan, I'm also researching on the same area. Could you please provide some details why you are implementing keep alive strategy? In other words, What problems prompted you to implement keep alive strategy? If you could elaborate on your issue, I could share some of my experience and research findings. Thanks, Raj -Original Message- From: Joan Balaguero [mailto:joan.balagu...@grupoventus.com] Sent: Thursday, March 31, 2011 11:13 AM To: 'HttpClient User Discussion' Subject: Keep alive Hello Oleg, I've implemented a Connection Keep Alive strategy in my app, but I'm not able to see what is the better way to check if it's working ok. Could you give any clue about how to do this? Thanks, Joan. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
RE: Keep alive
Hello,
Thanks, it seems to work. Keep-Alive = 10 seconds.
First request (creates new connection)
Get connection: HttpRoute[{}-http://10.20.30.105:80], timeout = 1
[HttpRoute[{}-http://10.20.30.105:80]] kept alive: 0, issued: 0, allocated:
0 out of 500
No free connections [HttpRoute[{}-http://10.20.30.105:80]][null]
Available capacity: 2147483647 out of 2147483647
[HttpRoute[{}-http://10.20.30.105:80]][null]
Creating new connection [HttpRoute[{}-http://10.20.30.105:80]]
Attempt 1 to execute request
Sending request: POST /wsserhs/rhodasol?a=1 HTTP/1.1
Receiving response: HTTP/1.1 200 OK
Connection can be kept alive for 1 ms
Released connection is reusable.
Releasing connection [HttpRoute[{}-http://10.20.30.105:80]][null]
Pooling connection [HttpRoute[{}-http://10.20.30.105:80]][null]; keep alive
for 1 MILLISECONDS
Adding connection at: 1301590475036
Notifying no-one, there are no waiting threads
Second request (takes previous connection from pool)
Get connection: HttpRoute[{}-http://10.20.30.105:80], timeout = 1
[HttpRoute[{}-http://10.20.30.105:80]] kept alive: 1, issued: 0, allocated:
1 out of 500
Getting free connection [HttpRoute[{}-http://10.20.30.105:80]][null]
Attempt 1 to execute request
Sending request: POST /wsserhs/rhodasol?a=1 HTTP/1.1
Receiving response: HTTP/1.1 200 OK
Connection can be kept alive for 1 ms
Released connection is reusable.
Releasing connection [HttpRoute[{}-http://10.20.30.105:80]][null]
Pooling connection [HttpRoute[{}-http://10.20.30.105:80]][null]; keep alive
for 1 MILLISECONDS
Adding connection at: 1301590476953
Notifying no-one, there are no waiting threads
Third request, after waiting more than 10 seconds (takes previous connection
from pool, but it's not alive -- close and create a new one)
Get connection: HttpRoute[{}-http://10.20.30.105:80], timeout = 1
[HttpRoute[{}-http://10.20.30.105:80]] kept alive: 1, issued: 0, allocated:
1 out of 500
Getting free connection [HttpRoute[{}-http://10.20.30.105:80]][null]
Closing expired free connection
[HttpRoute[{}-http://10.20.30.105:80]][null]
Connection closed
No free connections [HttpRoute[{}-http://10.20.30.105:80]][null]
Available capacity: 2147483647 out of 2147483647
[HttpRoute[{}-http://10.20.30.105:80]][null]
Creating new connection [HttpRoute[{}-http://10.20.30.105:80]]
Attempt 1 to execute request
Sending request: POST /wsserhs/rhodasol?a=1 HTTP/1.1
Receiving response: HTTP/1.1 200 OK
Connection can be kept alive for 1 ms
Released connection is reusable.
Releasing connection [HttpRoute[{}-http://10.20.30.105:80]][null]
Pooling connection [HttpRoute[{}-http://10.20.30.105:80]][null]; keep alive
for 1 MILLISECONDS
Adding connection at: 1301590655288
Notifying no-one, there are no waiting threads
-Mensaje original-
De: Sam Crawford [mailto:samcrawf...@gmail.com]
Enviado el: jueves, 31 de marzo de 2011 18:18
Para: HttpClient User Discussion
CC: Joan Balaguero
Asunto: Re: Keep alive
You can increase the logging level as per the Enable context logging
for connection management / request execution instructions listed on
http://hc.apache.org/httpcomponents-client-ga/logging.html
Alternatively, you could use tcpdump or Wireshark to capture the
packets and see if the same TCP connection is being re-used.
Thanks,
Sam
On 31 March 2011 17:12, Joan Balaguero joan.balagu...@grupoventus.com
wrote:
Hello Oleg,
Ive implemented a Connection Keep Alive strategy in my app, but Im not
able to see what is the better way to check if its working ok. Could you
give any clue about how to do this?
Thanks,
Joan.
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
RE: Keep alive
Hi Raj, In my case, I'm sending requests to problematic servers. By problematic I mean that they're abruptly closing the http sockets. That's why I'm not interested in keeping alive my http connections for so many time, because after few seconds (~10 seconds), they will be probably closed on the server side. In addition, it's also a good idea to implement an IdleConnection Handler to manage idle connections (and, in the same method, also call to 'closeExpiredConnections', recommendation made by Oleg to me some months ago) and also a 'Retry' handler. With this combination of strategies, you will minimize connection problems (like a 'Connection reset'), but you don't have to expect to solve the problems completely. Using Http protocol, you ALWAYS will lose requests due to connection problems. Regards, Joan. -Mensaje original- De: Vadheraju, Rajeshwar [mailto:rajeshwar.vadher...@fisglobal.com] Enviado el: jueves, 31 de marzo de 2011 18:19 Para: HttpClient User Discussion Asunto: RE: Keep alive Hi Joan, I'm also researching on the same area. Could you please provide some details why you are implementing keep alive strategy? In other words, What problems prompted you to implement keep alive strategy? If you could elaborate on your issue, I could share some of my experience and research findings. Thanks, Raj -Original Message- From: Joan Balaguero [mailto:joan.balagu...@grupoventus.com] Sent: Thursday, March 31, 2011 11:13 AM To: 'HttpClient User Discussion' Subject: Keep alive Hello Oleg, I've implemented a Connection Keep Alive strategy in my app, but I'm not able to see what is the better way to check if it's working ok. Could you give any clue about how to do this? Thanks, Joan. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ - 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: Keep alive
Yes, agreed. I think it is good idea to implement retry and idle connection handler as opposed to keep alive strategy. How did you implement or use idle connection thread? I am using xfire as my soap framework which uses MultiThreadedConnectionManager internally, not sure how to tell xfire to use or run IdleConenction Thread? -Original Message- From: Joan Balaguero [mailto:joan.balagu...@grupoventus.com] Sent: Thursday, March 31, 2011 12:50 PM To: Vadheraju, Rajeshwar Cc: 'HttpClient User Discussion' Subject: RE: Keep alive Hi Raj, In my case, I'm sending requests to problematic servers. By problematic I mean that they're abruptly closing the http sockets. That's why I'm not interested in keeping alive my http connections for so many time, because after few seconds (~10 seconds), they will be probably closed on the server side. In addition, it's also a good idea to implement an IdleConnection Handler to manage idle connections (and, in the same method, also call to 'closeExpiredConnections', recommendation made by Oleg to me some months ago) and also a 'Retry' handler. With this combination of strategies, you will minimize connection problems (like a 'Connection reset'), but you don't have to expect to solve the problems completely. Using Http protocol, you ALWAYS will lose requests due to connection problems. Regards, Joan. -Mensaje original- De: Vadheraju, Rajeshwar [mailto:rajeshwar.vadher...@fisglobal.com] Enviado el: jueves, 31 de marzo de 2011 18:19 Para: HttpClient User Discussion Asunto: RE: Keep alive Hi Joan, I'm also researching on the same area. Could you please provide some details why you are implementing keep alive strategy? In other words, What problems prompted you to implement keep alive strategy? If you could elaborate on your issue, I could share some of my experience and research findings. Thanks, Raj -Original Message- From: Joan Balaguero [mailto:joan.balagu...@grupoventus.com] Sent: Thursday, March 31, 2011 11:13 AM To: 'HttpClient User Discussion' Subject: Keep alive Hello Oleg, I've implemented a Connection Keep Alive strategy in my app, but I'm not able to see what is the better way to check if it's working ok. Could you give any clue about how to do this? Thanks, Joan. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
RE: Keep alive questions
On Fri, 2010-06-18 at 12:51 +0200, Joan Balaguero wrote: Hello Oleg, Thanks for your response. What I mean by removing keep alive strategy is the following. I have an administration application with the following option: [x] Keep alive http connection for [ ] seconds. If the user checks this option, he must enter a number greather than 0 as keep alive duration. Then I set my own KeepAliveStrategy with: this.objHttp.setKeepAliveStrategy(new VPFWConnectionKeepAliveStrategy(keepAliveDuration)); But now imagine that the same user unchecks this option. Then, I should apply the default keep alive strategy. And what is this? Keep alive indefinitely? Pass to 'VPFWConnectionKeepAliveStrategy' an Integer.MAX_VALUE value? Check Keep-Alive header, if not found, keep alive indefinitely. Oleg - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
RE: Keep alive questions
Ok, then my 'getKeepAliveDuration' method should do: 1. If the user enters a 'keepAliveDuration' ( 0) -- return this value. 2. If the user does not check 'keep-alive', then: 2.1. if 'keep-alive' header exists -- return its value. 2.2. if not, return Integer.MAX_VALUE. Is this right? Thanks, Joan. -Mensaje original- De: Oleg Kalnichevski [mailto:ol...@apache.org] Enviado el: viernes, 18 de junio de 2010 13:44 Para: HttpClient User Discussion Asunto: RE: Keep alive questions On Fri, 2010-06-18 at 12:51 +0200, Joan Balaguero wrote: Hello Oleg, Thanks for your response. What I mean by removing keep alive strategy is the following. I have an administration application with the following option: [x] Keep alive http connection for [ ] seconds. If the user checks this option, he must enter a number greather than 0 as keep alive duration. Then I set my own KeepAliveStrategy with: this.objHttp.setKeepAliveStrategy(new VPFWConnectionKeepAliveStrategy(keepAliveDuration)); But now imagine that the same user unchecks this option. Then, I should apply the default keep alive strategy. And what is this? Keep alive indefinitely? Pass to 'VPFWConnectionKeepAliveStrategy' an Integer.MAX_VALUE value? Check Keep-Alive header, if not found, keep alive indefinitely. Oleg - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.829 / Virus Database: 271.1.1/2944 - Release Date: 06/18/10 08:35:00 - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Why client connection's port changed always when server support Keep-alive?
:29,838 DEBUG DefaultRequestDirector:408 - Attempt 1 to execute request
10:27:29,838 DEBUG wire:78 - POST /router/rest HTTP/1.1[EOL]
10:27:29,853 DEBUG wire:78 - Content-Length: 188[EOL]
10:27:29,853 DEBUG wire:78 - Content-Type:
application/x-www-form-urlencoded[EOL]
10:27:29,853 DEBUG wire:78 - Host: 192.168.208.110[EOL]
10:27:29,853 DEBUG wire:78 - Connection: Keep-Alive[EOL]
10:27:29,853 DEBUG wire:78 - [EOL]
10:27:29,853 DEBUG headers:251 - POST /router/rest HTTP/1.1
10:27:29,853 DEBUG headers:254 - Content-Length: 188
10:27:29,853 DEBUG headers:254 - Content-Type:
application/x-www-form-urlencoded
10:27:29,853 DEBUG headers:254 - Host: 192.168.208.110
10:27:29,853 DEBUG headers:254 - Connection: Keep-Alive
10:27:29,853 DEBUG wire:78 -
fields=name%2Cbuyer_credit%2Cphone%2Creal_nametimestamp=2008-12-25+10%3A27%3A29api_key=suibiannick=tbtest5method=taobao.user.getsign=82D375615F2EC704D9DAD60992359B3Aformat=jsonv=1.0
10:27:29,869 DEBUG wire:78 - HTTP/1.1 200 OK[EOL]
10:27:29,869 DEBUG wire:78 - Date: Thu, 25 Dec 2008 02:26:40 GMT[EOL]
10:27:29,869 DEBUG wire:78 - Server: Apache-Coyote/1.1[EOL]
10:27:29,869 DEBUG wire:78 - X-Powered-By: Servlet 2.4;
JBoss-4.2.2.GA(build: SVNTag=JBoss_4_2_2_GA
date=200710221139)/Tomcat-5.5[EOL]
10:27:29,869 DEBUG wire:78 - Content-Type:
text/javascript;charset=UTF-8[EOL]
10:27:29,869 DEBUG wire:78 - Content-Length: 85[EOL]
10:27:29,885 DEBUG wire:78 - Vary: Accept-Encoding[EOL]
10:27:29,885 DEBUG wire:78 - Keep-Alive: timeout=15, max=100[EOL]
10:27:29,885 DEBUG wire:78 - Connection: Keep-Alive[EOL]
10:27:29,885 DEBUG headers:237 - HTTP/1.1 200 OK
10:27:29,885 DEBUG headers:240 - Date: Thu, 25 Dec 2008 02:26:40 GMT
10:27:29,885 DEBUG headers:240 - Server: Apache-Coyote/1.1
10:27:29,885 DEBUG headers:240 - X-Powered-By: Servlet 2.4;
JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5
10:27:29,885 DEBUG headers:240 - Content-Type:
text/javascript;charset=UTF-8
10:27:29,885 DEBUG headers:240 - Content-Length: 85
10:27:29,885 DEBUG headers:240 - Vary: Accept-Encoding
10:27:29,885 DEBUG headers:240 - Keep-Alive: timeout=15, max=100
10:27:29,885 DEBUG headers:240 - Connection: Keep-Alive
10:27:29,900 DEBUG DefaultRequestDirector:463 - Connection can be kept alive
for 15000 ms
10:27:29,900 DEBUG wire:78 -
{rsp:{users:[{buyer_credit:{good_num:1,level:0,score:1,total_num:1}}]}}
10:27:29,900 DEBUG ThreadSafeClientConnManager:221 - Released connection is
reusable.
10:27:29,900 DEBUG ConnPoolByRoute:374 - Releasing connection
[HttpRoute[{}-http://192.168.208.110]][null]
10:27:29,900 DEBUG ConnPoolByRoute:394 - Pooling connection [HttpRoute[{}-
http://192.168.208.110]][null]; keep alive for 15000 MILLISECONDS
10:27:29,900 DEBUG IdleConnectionHandler:78 - Adding connection at:
1230172049900
10:27:29,900 DEBUG ConnPoolByRoute:631 - Notifying no-one, there are no
waiting threads
- finish first send
10:27:29,916 DEBUG ClientParamsStack:219 - 'http.conn-manager.timeout': 5000
10:27:29,916 DEBUG ThreadSafeClientConnManager:171 -
ThreadSafeClientConnManager.getConnection: HttpRoute[{}-
http://192.168.208.110], timeout = 5000
10:27:29,916 DEBUG ConnPoolByRoute:289 - Total connections kept alive: 1
10:27:29,916 DEBUG ConnPoolByRoute:290 - Total issued connections: 0
10:27:29,916 DEBUG ConnPoolByRoute:291 - Total allocated connection: 1 out
of 1000
10:27:29,916 DEBUG ConnPoolByRoute:436 - Getting free connection
[HttpRoute[{}-http://192.168.208.110]][null]
10:27:29,916 DEBUG DefaultRequestDirector:334 - Stale connection check
10:27:29,932 DEBUG ClientParamsStack:219 - 'http.protocol.version': HTTP/1.1
10:27:29,932 DEBUG RequestAddCookies:125 - CookieSpec selected: best-match
10:27:29,932 DEBUG DefaultRequestDirector:408 - Attempt 1 to execute request
10:27:29,932 DEBUG wire:78 - POST /router/rest HTTP/1.1[EOL]
10:27:29,932 DEBUG wire:78 - Content-Length: 188[EOL]
10:27:29,932 DEBUG wire:78 - Content-Type:
application/x-www-form-urlencoded[EOL]
10:27:29,932 DEBUG wire:78 - Host: 192.168.208.110[EOL]
10:27:29,932 DEBUG wire:78 - Connection: Keep-Alive[EOL]
10:27:29,932 DEBUG wire:78 - [EOL]
10:27:29,932 DEBUG headers:251 - POST /router/rest HTTP/1.1
10:27:29,932 DEBUG headers:254 - Content-Length: 188
10:27:29,932 DEBUG headers:254 - Content-Type:
application/x-www-form-urlencoded
10:27:29,932 DEBUG headers:254 - Host: 192.168.208.110
10:27:29,932 DEBUG headers:254 - Connection: Keep-Alive
10:27:29,932 DEBUG wire:78 -
fields=name%2Cbuyer_credit%2Cphone%2Creal_nametimestamp=2008-12-25+10%3A27%3A29api_key=suibiannick=tbtest5method=taobao.user.getsign=82D375615F2EC704D9DAD60992359B3Aformat=jsonv=1.0
10:27:29,963 DEBUG wire:78 - HTTP/1.1 200 OK[EOL]
10:27:29,963 DEBUG wire:78 - Date: Thu, 25 Dec 2008 02:26:40 GMT[EOL]
10:27:29,963 DEBUG wire:78 - Server: Apache-Coyote/1.1[EOL]
10:27:29,963 DEBUG wire:78 - X-Powered-By: Servlet 2.4;
JBoss-4.2.2.GA(build: SVNTag=JBoss_4_2_2_GA
date=200710221139)/Tomcat-5.5[EOL]
10
Re: Why client connection's port changed always when server support Keep-alive?
On Mon, 2008-12-22 at 17:46 +0800, alin(王霖) wrote:
HI:
I use httpclient3 and httpclient4 for a multi-thread load test, and
always set http request header with Connection:Keep-Alive.
When i input command netstat -na | grep myserverhost:myserverport in
console(My system is windows xp + cygwin) , output like following:
C:\Documents and Settings\lin.wanglnetstat -na | grep 192.168.208.110:80
TCP10.1.26.82:4159192.168.208.110:80 ESTABLISHED
TCP10.1.26.82:4160192.168.208.110:80 ESTABLISHED
But the ports of client connections(here is 10.1.26.82) is changing while
load test is running.
through log4j, httpclient4 told me:
17:33:33,049 DEBUG DefaultRequestDirector:463 - Connection can be kept alive
for 15000 ms
17:33:33,065 DEBUG ThreadSafeClientConnManager:221 - Released connection is
reusable.
17:33:33,065 DEBUG ConnPoolByRoute:374 - Releasing connection
[HttpRoute[{}-http://192.168.208.110]][null]
17:33:33,065 DEBUG ConnPoolByRoute:394 - Pooling connection [HttpRoute[{}-
http://192.168.208.110]][null]; keep alive for 15000 MILLISECONDS
Who can tell me why this is?
It is just not possible to tell from 16 milliseconds of logs.
Oleg
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Why client connection's port changed always when server support Keep-alive?
Dear Oleg:
Thanks for your reply. And here is my simple code (usging
httpclient4.0-beta2):
private void initHttpClient() {
SchemeRegistry schemeRegistry = new SchemeRegistry();
schemeRegistry.register(
new Scheme(http, PlainSocketFactory.getSocketFactory(),
80));
httpParams = new BasicHttpParams();
HttpProtocolParams.setVersion(httpParams, HttpVersion.HTTP_1_1);
this.setMaxTotalConnections(DEFAULT_MAX_TOTAL_CONNECTIONS);
this.setReadTimeout(DEFAULT_READ_TIMEOUT);
ClientConnectionManager cm = new ThreadSafeClientConnManager(
httpParams, schemeRegistry);
httpClient = new DefaultHttpClient(cm, httpParams);
}
On Tue, Dec 23, 2008 at 10:51 PM, Oleg Kalnichevski ol...@apache.orgwrote:
On Mon, 2008-12-22 at 17:46 +0800, alin(王霖) wrote:
HI:
I use httpclient3 and httpclient4 for a multi-thread load test, and
always set http request header with Connection:Keep-Alive.
When i input command netstat -na | grep myserverhost:myserverport in
console(My system is windows xp + cygwin) , output like following:
C:\Documents and Settings\lin.wanglnetstat -na | grep
192.168.208.110:80
TCP10.1.26.82:4159192.168.208.110:80 ESTABLISHED
TCP10.1.26.82:4160192.168.208.110:80 ESTABLISHED
But the ports of client connections(here is 10.1.26.82) is changing
while
load test is running.
through log4j, httpclient4 told me:
17:33:33,049 DEBUG DefaultRequestDirector:463 - Connection can be kept
alive
for 15000 ms
17:33:33,065 DEBUG ThreadSafeClientConnManager:221 - Released connection
is
reusable.
17:33:33,065 DEBUG ConnPoolByRoute:374 - Releasing connection
[HttpRoute[{}-http://192.168.208.110]][null]
17:33:33,065 DEBUG ConnPoolByRoute:394 - Pooling connection
[HttpRoute[{}-
http://192.168.208.110]][null]; keep alive for 15000 MILLISECONDS
Who can tell me why this is?
It is just not possible to tell from 16 milliseconds of logs.
Oleg
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
--
Yours sincerely
alin
Why client connection's port changed always when server support Keep-alive?
HI:
I use httpclient3 and httpclient4 for a multi-thread load test, and
always set http request header with Connection:Keep-Alive.
When i input command netstat -na | grep myserverhost:myserverport in
console(My system is windows xp + cygwin) , output like following:
C:\Documents and Settings\lin.wanglnetstat -na | grep 192.168.208.110:80
TCP10.1.26.82:4159192.168.208.110:80 ESTABLISHED
TCP10.1.26.82:4160192.168.208.110:80 ESTABLISHED
But the ports of client connections(here is 10.1.26.82) is changing while
load test is running.
through log4j, httpclient4 told me:
17:33:33,049 DEBUG DefaultRequestDirector:463 - Connection can be kept alive
for 15000 ms
17:33:33,065 DEBUG ThreadSafeClientConnManager:221 - Released connection is
reusable.
17:33:33,065 DEBUG ConnPoolByRoute:374 - Releasing connection
[HttpRoute[{}-http://192.168.208.110]][null]
17:33:33,065 DEBUG ConnPoolByRoute:394 - Pooling connection [HttpRoute[{}-
http://192.168.208.110]][null]; keep alive for 15000 MILLISECONDS
Who can tell me why this is?
--
best Regards
alin
Re: Keep-alive, stale connections and socket reuse
Thank you for the answers! Regards, Dobri On Tue, Sep 2, 2008 at 9:20 PM, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Mon, 2008-09-01 at 17:27 +0300, Dobri Kitipov wrote: Hi Oleg, I have one additional more abstract question. What I have observed during my tests was that when I run my test scenarion with 5 WS consecutive invocations and sniff the traffic I can see that the sockets were reused. The problem is that when I first tried to debug the source it always invoked the org.apache.commons.httpclient.HttpConnection isStale() method. This is happening when there are more breakpoints set. If I set only a breakpoint into the isStale() method then the socket is reused and no new connection is opened for every invocation. It seems it is a timeout issue or a thread issue to me? Do you suspect what may cause this? I have tried to set SO_TIMEOUT and CONNECTION_TIMEOUT to 0, but without success. Any hints? Not a slightest idea. It can well be the stale connection check just does not work reliably when run in the debug mode Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep-alive, stale connections and socket reuse
On Mon, 2008-09-01 at 17:27 +0300, Dobri Kitipov wrote: Hi Oleg, I have one additional more abstract question. What I have observed during my tests was that when I run my test scenarion with 5 WS consecutive invocations and sniff the traffic I can see that the sockets were reused. The problem is that when I first tried to debug the source it always invoked the org.apache.commons.httpclient.HttpConnection isStale() method. This is happening when there are more breakpoints set. If I set only a breakpoint into the isStale() method then the socket is reused and no new connection is opened for every invocation. It seems it is a timeout issue or a thread issue to me? Do you suspect what may cause this? I have tried to set SO_TIMEOUT and CONNECTION_TIMEOUT to 0, but without success. Any hints? Not a slightest idea. It can well be the stale connection check just does not work reliably when run in the debug mode Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep-alive, stale connections and socket reuse
On Mon, 2008-09-01 at 16:33 +0300, Dobri Kitipov wrote: Hi Oleg, thank you for the detailed answer of my question. It seems we need to recommend the Axis2 guys to use the better version. Do you know when there will be an official release of HttpClient 4.0-beta1? Thank you, Dobri HttpClient 4.0-beta1 has been officially released a few days ago. You can get it here: http://hc.apache.org/downloads.cgi Unfortunately, Axis2 kernel is tightly coupled with HttpClient 3.1. AXIS2-3933 [1] would need to be resolved first. Oleg [1] https://issues.apache.org/jira/browse/AXIS2-3933 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep-alive, stale connections and socket reuse
Hi Oleg, thank you for the detailed answer of my question. It seems we need to recommend the Axis2 guys to use the better version. Do you know when there will be an official release of HttpClient 4.0-beta1? Thank you, Dobri On Fri, Aug 29, 2008 at 2:11 PM, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Thu, 2008-08-28 at 14:51 +0300, Dobri Kitipov wrote: Hi, I am trying to explain myself how the keep-alive, or TCP connection persistence, is supposed to work? I have read several resources about that, but I still have some questions ( http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html http://hc.apache.org/httpclient-3.x/performance.html http://www.io.com/~maus/HttpKeepAlive.htmlhttp://www.io.com/%7Emaus/HttpKeepAlive.html http://www.io.com/%7Emaus/HttpKeepAlive.html ). How can I verify that keep-alive is really used? I know that for http 1.1 keep-alive is by default, but does it mean that the TCP socket is reused? Yes, it does. I mean how can I debug and verify that a TCP connection is reused. Does it mean that a socket is reused? Turning on the context logging would be one option. I have executed several debug sessions using as a sample an Axis2 1.4 client, that in turns uses commons-httpclient-3.1. When I set client option: options.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, true); Having two web services invocations from my client I can see that the HttpClient is really reused when the prop is set. The http connection used is of type MultiThreadedHttpConnectionManager$HttpConnectionAdapter The problem is that here stale connection check is enabled, so when the check is done as a consequence the connection (and its corresponding socket) used is closed and a new one is opened. In some cases the stale connection check can report a perfectly valid connection as stale. I would strongly recommend disabling it. I can read from http://hc.apache.org/httpclient-3.x/preference-api.htmlthat: Disabling stale connection check may result in *slight* *performance*improvement at the risk of getting an I/O error when executing a request over a connection that has been closed at the server side. My general understanding is that in order to have a better performance a connection should be reused and its socket,too? Yes. My question is if it is a bad practice to disable stale connection check in order to reuse the connection and its socket? No, it is not. You just have to make sure your application can react intelligently to I/O exceptions caused by attempts to re-use a stale connection. Why in commons-httpclient it is preferred to close and open a new connection: Only if a connection is believed to have been closed on the other end (is stale). Where I can read more about the benefit/tradeoff of having stale conn check? It is recommended to have a reasonable recovery strategy or/and eviction policy for idle connections in place instead of relying on relatively expensive and not always reliable stale connection check. Hope this helps Oleg PS: You may also consider upgrading to HttpClient 4.0-beta1 which has a _much_ better and robust connection management code compared to HttpClient 3.x. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Keep-alive, stale connections and socket reuse
Hi,
I am trying to explain myself how the keep-alive, or TCP connection
persistence, is supposed to work? I have read several resources about that,
but I still have some questions (
http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html
http://hc.apache.org/httpclient-3.x/performance.html
http://www.io.com/~maus/HttpKeepAlive.htmlhttp://www.io.com/%7Emaus/HttpKeepAlive.html
).
How can I verify that keep-alive is really used? I know that for http 1.1
keep-alive is by default, but does it mean that the TCP socket is reused? I
mean how can I debug and verify that a TCP connection is reused. Does it
mean that a socket is reused?
I have executed several debug sessions using as a sample an Axis2 1.4
client, that in turns uses commons-httpclient-3.1.
When I set client option:
options.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, true);
Having two web services invocations from my client I can see that the
HttpClient is really reused when the prop is set. The http connection used
is of type MultiThreadedHttpConnectionManager$HttpConnectionAdapter
The problem is that here stale connection check is enabled, so when the
check is done as a consequence the connection (and its corresponding socket)
used is closed and a new one is opened.
I can read from http://hc.apache.org/httpclient-3.x/preference-api.htmlthat:
Disabling stale connection check may result in *slight*
*performance*improvement at the risk of getting an I/O error when
executing a request
over a connection that has been closed at the server side.
My general understanding is that in order to have a better performance a
connection should be reused and its socket,too?
My question is if it is a bad practice to disable stale connection check in
order to reuse the connection and its socket? Why in commons-httpclient it
is preferred to close and open a new connection:
org.apache.commons.httpclient HttpMethodDirector
private void executeWithRetry(final HttpMethod method):
….
if (this.conn.getParams().isStaleCheckingEnabled()) {
this.conn.closeIfStale(); - this is executed
}
….
Where I can read more about the benefit/tradeoff of having stale conn check?
I will appreciate any information on the topic, because I have no much
knowledge into this field.
Thank you in advance,
Dobri
