You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Thomas Boniface <th...@stickyads.tv> on 2014/01/28 18:00:56 UTC
Cancel and socket state
Hi,
I am using an http async client to contact several endpoints in a row with
the same process. In the context of my application I want to keep the
global process under a certain time. Sometimes it happens some of the
executes I triggered using the client did not respond before what I
consider to be a reasonable time.
In such a case I used to call cancel on the Future object returned by the
execute in order to free the socket used by this execute as soon as
possible (as I don't need the response anymore). The thing is it appears
that the socket is closed instead of being put back in the pool when I call
the cancel (The socket appears in TIME_WAIT state when I use netstat
whereas when there is no timeout the socket appears as ESTABLISHED).
Is this an expected behavior ?
Thanks,
Thomas
Re: Cancel and socket state
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-01-30 at 10:47 +0100, Thomas Boniface wrote:
> Oleg,
>
> Concerning the unsafe underlying connections you mention. Do I have to
> explicitly discard them myself or does the http async client handles this
> by itslef ?
HC will take care of that automatically.
> Also if the client does the job, when does it triggers the
> cleaning (on regular basis, on low load) ?
>
Upon connection release. No connections with an inconsistent state
should ever end up in the pool.
I found and fixed the bug which caused the problem with connection
re-use in case of response future cancellation.
http://svn.apache.org/viewvc/httpcomponents/httpasyncclient/trunk/httpasyncclient/src/main/java/org/apache/http/impl/nio/client/DefaultClientExchangeHandlerImpl.java?r1=1562788&r2=1562787&pathrev=1562788
Please pull the latest source or get the latest snapshot from the
snapshot repository.
Oleg
> Thanks
>
> 2014-01-30 Oleg Kalnichevski <ol...@apache.org>:
>
> > On Thu, 2014-01-30 at 09:49 +0100, Thomas Boniface wrote:
> > > In case I don't do the cancel the connection is released and only
> > > disconnected once the keep alive timeout is reached.
> > >
> >
> > This is a very important bit of information. I'll see if I can reproduce
> > the same behavior locally.
> >
> > > I experience a file descriptor leak in my tomcat process and I was
> > > suspecting the request cancellation may be the source cause but it
> > appears
> > > it does not as not canceling the request do not solve the issue. Though I
> > > was expecting that canceling the request would get the connection back in
> > > the pool sooner that letting the request I don't need anymore finish.
> > >
> >
> > Please note that if an HTTP exchange cannot be fully completed the
> > underlying connection is simply unsafe to re-use and needs to be
> > discarded.
> >
> > Oleg
> >
> > > I will try to reproduce my leak issue in a simpler context.
> > >
> > > Thomas
> > >
> > >
> > > 2014-01-29 Oleg Kalnichevski <ol...@apache.org>:
> > >
> > > > On January 29, 2014 5:38:13 PM CET, Thomas Boniface <
> > thomas@stickyads.tv>
> > > > wrote:
> > > > >Thanks for your help regarding the snapshot. Here is an updated log
> > > > >using
> > > > >the 4.0.1-SNAPSHOT.
> > > > >
> > > > >Regarding request cancel, it is done as follow:
> > > > >
> > > > >if (futureHttpResponse != null && !futureHttpResponse.isCancelled()) {
> > > > > futureHttpResponse.cancel(true);
> > > > >}
> > > > >
> > > > >where futureHttpResponse what the object return by the execute call.
> > > > >
> > > > >Thomas
> > > >
> > > > Thomas,
> > > > I am sorry I cannot reduce the cause of the problem just by looking at
> > the
> > > > log.
> > > >
> > > > What happens if you do not cancel the request? Does the connection get
> > > > returned to the pool?
> > > >
> > > > Oleg
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > > >
> > > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Cancel and socket state
Posted by Thomas Boniface <th...@stickyads.tv>.
Oleg,
Concerning the unsafe underlying connections you mention. Do I have to
explicitly discard them myself or does the http async client handles this
by itslef ? Also if the client does the job, when does it triggers the
cleaning (on regular basis, on low load) ?
Thanks
2014-01-30 Oleg Kalnichevski <ol...@apache.org>:
> On Thu, 2014-01-30 at 09:49 +0100, Thomas Boniface wrote:
> > In case I don't do the cancel the connection is released and only
> > disconnected once the keep alive timeout is reached.
> >
>
> This is a very important bit of information. I'll see if I can reproduce
> the same behavior locally.
>
> > I experience a file descriptor leak in my tomcat process and I was
> > suspecting the request cancellation may be the source cause but it
> appears
> > it does not as not canceling the request do not solve the issue. Though I
> > was expecting that canceling the request would get the connection back in
> > the pool sooner that letting the request I don't need anymore finish.
> >
>
> Please note that if an HTTP exchange cannot be fully completed the
> underlying connection is simply unsafe to re-use and needs to be
> discarded.
>
> Oleg
>
> > I will try to reproduce my leak issue in a simpler context.
> >
> > Thomas
> >
> >
> > 2014-01-29 Oleg Kalnichevski <ol...@apache.org>:
> >
> > > On January 29, 2014 5:38:13 PM CET, Thomas Boniface <
> thomas@stickyads.tv>
> > > wrote:
> > > >Thanks for your help regarding the snapshot. Here is an updated log
> > > >using
> > > >the 4.0.1-SNAPSHOT.
> > > >
> > > >Regarding request cancel, it is done as follow:
> > > >
> > > >if (futureHttpResponse != null && !futureHttpResponse.isCancelled()) {
> > > > futureHttpResponse.cancel(true);
> > > >}
> > > >
> > > >where futureHttpResponse what the object return by the execute call.
> > > >
> > > >Thomas
> > >
> > > Thomas,
> > > I am sorry I cannot reduce the cause of the problem just by looking at
> the
> > > log.
> > >
> > > What happens if you do not cancel the request? Does the connection get
> > > returned to the pool?
> > >
> > > Oleg
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: Cancel and socket state
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-01-30 at 09:49 +0100, Thomas Boniface wrote:
> In case I don't do the cancel the connection is released and only
> disconnected once the keep alive timeout is reached.
>
This is a very important bit of information. I'll see if I can reproduce
the same behavior locally.
> I experience a file descriptor leak in my tomcat process and I was
> suspecting the request cancellation may be the source cause but it appears
> it does not as not canceling the request do not solve the issue. Though I
> was expecting that canceling the request would get the connection back in
> the pool sooner that letting the request I don't need anymore finish.
>
Please note that if an HTTP exchange cannot be fully completed the
underlying connection is simply unsafe to re-use and needs to be
discarded.
Oleg
> I will try to reproduce my leak issue in a simpler context.
>
> Thomas
>
>
> 2014-01-29 Oleg Kalnichevski <ol...@apache.org>:
>
> > On January 29, 2014 5:38:13 PM CET, Thomas Boniface <th...@stickyads.tv>
> > wrote:
> > >Thanks for your help regarding the snapshot. Here is an updated log
> > >using
> > >the 4.0.1-SNAPSHOT.
> > >
> > >Regarding request cancel, it is done as follow:
> > >
> > >if (futureHttpResponse != null && !futureHttpResponse.isCancelled()) {
> > > futureHttpResponse.cancel(true);
> > >}
> > >
> > >where futureHttpResponse what the object return by the execute call.
> > >
> > >Thomas
> >
> > Thomas,
> > I am sorry I cannot reduce the cause of the problem just by looking at the
> > log.
> >
> > What happens if you do not cancel the request? Does the connection get
> > returned to the pool?
> >
> > Oleg
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Cancel and socket state
Posted by Thomas Boniface <th...@stickyads.tv>.
In case I don't do the cancel the connection is released and only
disconnected once the keep alive timeout is reached.
I experience a file descriptor leak in my tomcat process and I was
suspecting the request cancellation may be the source cause but it appears
it does not as not canceling the request do not solve the issue. Though I
was expecting that canceling the request would get the connection back in
the pool sooner that letting the request I don't need anymore finish.
I will try to reproduce my leak issue in a simpler context.
Thomas
2014-01-29 Oleg Kalnichevski <ol...@apache.org>:
> On January 29, 2014 5:38:13 PM CET, Thomas Boniface <th...@stickyads.tv>
> wrote:
> >Thanks for your help regarding the snapshot. Here is an updated log
> >using
> >the 4.0.1-SNAPSHOT.
> >
> >Regarding request cancel, it is done as follow:
> >
> >if (futureHttpResponse != null && !futureHttpResponse.isCancelled()) {
> > futureHttpResponse.cancel(true);
> >}
> >
> >where futureHttpResponse what the object return by the execute call.
> >
> >Thomas
>
> Thomas,
> I am sorry I cannot reduce the cause of the problem just by looking at the
> log.
>
> What happens if you do not cancel the request? Does the connection get
> returned to the pool?
>
> Oleg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: Cancel and socket state
Posted by Oleg Kalnichevski <ol...@apache.org>.
On January 29, 2014 5:38:13 PM CET, Thomas Boniface <th...@stickyads.tv> wrote:
>Thanks for your help regarding the snapshot. Here is an updated log
>using
>the 4.0.1-SNAPSHOT.
>
>Regarding request cancel, it is done as follow:
>
>if (futureHttpResponse != null && !futureHttpResponse.isCancelled()) {
> futureHttpResponse.cancel(true);
>}
>
>where futureHttpResponse what the object return by the execute call.
>
>Thomas
Thomas,
I am sorry I cannot reduce the cause of the problem just by looking at the log.
What happens if you do not cancel the request? Does the connection get returned to the pool?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Cancel and socket state
Posted by Thomas Boniface <th...@stickyads.tv>.
Thanks for your help regarding the snapshot. Here is an updated log using
the 4.0.1-SNAPSHOT.
Regarding request cancel, it is done as follow:
if (futureHttpResponse != null && !futureHttpResponse.isCancelled()) {
futureHttpResponse.cancel(true);
}
where futureHttpResponse what the object return by the execute call.
Thomas
2014-01-29 Oleg Kalnichevski <ol...@apache.org>
> On Wed, 2014-01-29 at 16:36 +0100, Thomas Boniface wrote:
> > I can't get my hand on the snapshot can you give a pointer ?
> >
> > It doesn't appear to be available at:
> >
> https://repository.apache.org/content/repositories/snapshots/org/apache/httpcomponents/
> >
> > Nor I can download it using maven: mvn
> > org.apache.maven.plugins:maven-dependency-plugin:2.4:get
> > -DartifactId=httpcomponents-asyncclient
> -DgroupId=org.apache.httpcomponents
> > -Dversion=4.0.1-SNAPSHOT
> >
> > Thanks
> >
>
> Thomas
>
> It is generally preferred to build snapshots from source [1][2]. That
> way one can be sure to get the latest.
>
> If that makes your life easier though I just deployed the latest
> snapshot to the ASF snapshot repository [3]
>
> Oleg
>
> [1]
> http://svn.apache.org/repos/asf/httpcomponents/httpasyncclient/trunk/
> [2] https://github.com/apache/httpasyncclient
> [3]
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/httpcomponents/httpasyncclient/4.0.1-SNAPSHOT/
>
> >
> >
> > 2014-01-29 Oleg Kalnichevski <ol...@apache.org>
> >
> > > On Wed, 2014-01-29 at 14:21 +0100, Thomas Boniface wrote:
> > > > Hi Oleg,
> > > >
> > > > Here is a log with the wire and context log for the behavior I
> described
> > > > before. I obfuscated business related details in the log but most
> of the
> > > > interesting things should be there.
> > > >
> > > > Thanks,
> > > > Thomas
> > > >
> > > >
> > >
> > > For some reason the client considers the connection to be an
> > > inconsistent state and drops it. I cannot figure out why just by
> looking
> > > at the log.
> > >
> > > Could you please do the following: upgrade to the latest
> 4.0.1-SNAPSHOT,
> > > re-run the test and re-post the log as well as let me know exactly how
> > > your application cancels the request?
> > >
> > > Oleg
> > >
> > > >
> > > > 2014-01-29 Oleg Kalnichevski <ol...@apache.org>
> > > >
> > > > > On Wed, 2014-01-29 at 10:42 +0100, Thomas Boniface wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I am using the httpasyncclient 4.0.
> > > > > >
> > > > > > Thomas
> > > > > >
> > > > >
> > > > > Then, things do not quite add up. If one cancels the result future,
> > > this
> > > > > should have no impact on the ongoing request execution. The request
> > > > > still gets fully executed, the response gets fully processed and
> the
> > > > > underlying connection gets returned back to the pool (provided it
> can
> > > be
> > > > > kept alive). The future is simply considered done and will receive
> no
> > > > > result notification.
> > > > >
> > > > > Please note though that connections cannot be kept alive in some
> cases.
> > > > > So, it is perfectly normal that the socket may end up in the
> TIME_WAIT
> > > > > state after the response has been fully processed.
> > > > >
> > > > > Wire / context log should help find out why the connection needs
> to be
> > > > > closed.
> > > > >
> > > > > http://hc.apache.org/httpcomponents-client-4.3.x/logging.html
> > > > >
> > > > > Oleg
> > > > >
> > > > > >
> > > > > > 2014-01-29 Oleg Kalnichevski <ol...@apache.org>
> > > > > >
> > > > > > > On Tue, 2014-01-28 at 18:00 +0100, Thomas Boniface wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I am using an http async client to contact several endpoints
> in
> > > a row
> > > > > > > with
> > > > > > > > the same process. In the context of my application I want to
> > > keep the
> > > > > > > > global process under a certain time. Sometimes it happens
> some
> > > of the
> > > > > > > > executes I triggered using the client did not respond before
> > > what I
> > > > > > > > consider to be a reasonable time.
> > > > > > > >
> > > > > > > > In such a case I used to call cancel on the Future object
> > > returned
> > > > > by the
> > > > > > > > execute in order to free the socket used by this execute as
> soon
> > > as
> > > > > > > > possible (as I don't need the response anymore). The thing
> is it
> > > > > appears
> > > > > > > > that the socket is closed instead of being put back in the
> pool
> > > when
> > > > > I
> > > > > > > call
> > > > > > > > the cancel (The socket appears in TIME_WAIT state when I use
> > > netstat
> > > > > > > > whereas when there is no timeout the socket appears as
> > > ESTABLISHED).
> > > > > > > >
> > > > > > > > Is this an expected behavior ?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Thomas
> > > > > > >
> > > > > > > Thomas,
> > > > > > >
> > > > > > > What version of HttpAsyncClient are you using?
> > > > > > >
> > > > > > > Oleg
> > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
> httpclient-users-unsubscribe@hc.apache.org
> > > > > > > For additional commands, e-mail:
> > > httpclient-users-help@hc.apache.org
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > > > For additional commands, e-mail:
> httpclient-users-help@hc.apache.org
> > > > >
> > > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: Cancel and socket state
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2014-01-29 at 16:36 +0100, Thomas Boniface wrote:
> I can't get my hand on the snapshot can you give a pointer ?
>
> It doesn't appear to be available at:
> https://repository.apache.org/content/repositories/snapshots/org/apache/httpcomponents/
>
> Nor I can download it using maven: mvn
> org.apache.maven.plugins:maven-dependency-plugin:2.4:get
> -DartifactId=httpcomponents-asyncclient -DgroupId=org.apache.httpcomponents
> -Dversion=4.0.1-SNAPSHOT
>
> Thanks
>
Thomas
It is generally preferred to build snapshots from source [1][2]. That
way one can be sure to get the latest.
If that makes your life easier though I just deployed the latest
snapshot to the ASF snapshot repository [3]
Oleg
[1]
http://svn.apache.org/repos/asf/httpcomponents/httpasyncclient/trunk/
[2] https://github.com/apache/httpasyncclient
[3]
https://repository.apache.org/content/repositories/snapshots/org/apache/httpcomponents/httpasyncclient/4.0.1-SNAPSHOT/
>
>
> 2014-01-29 Oleg Kalnichevski <ol...@apache.org>
>
> > On Wed, 2014-01-29 at 14:21 +0100, Thomas Boniface wrote:
> > > Hi Oleg,
> > >
> > > Here is a log with the wire and context log for the behavior I described
> > > before. I obfuscated business related details in the log but most of the
> > > interesting things should be there.
> > >
> > > Thanks,
> > > Thomas
> > >
> > >
> >
> > For some reason the client considers the connection to be an
> > inconsistent state and drops it. I cannot figure out why just by looking
> > at the log.
> >
> > Could you please do the following: upgrade to the latest 4.0.1-SNAPSHOT,
> > re-run the test and re-post the log as well as let me know exactly how
> > your application cancels the request?
> >
> > Oleg
> >
> > >
> > > 2014-01-29 Oleg Kalnichevski <ol...@apache.org>
> > >
> > > > On Wed, 2014-01-29 at 10:42 +0100, Thomas Boniface wrote:
> > > > > Hi,
> > > > >
> > > > > I am using the httpasyncclient 4.0.
> > > > >
> > > > > Thomas
> > > > >
> > > >
> > > > Then, things do not quite add up. If one cancels the result future,
> > this
> > > > should have no impact on the ongoing request execution. The request
> > > > still gets fully executed, the response gets fully processed and the
> > > > underlying connection gets returned back to the pool (provided it can
> > be
> > > > kept alive). The future is simply considered done and will receive no
> > > > result notification.
> > > >
> > > > Please note though that connections cannot be kept alive in some cases.
> > > > So, it is perfectly normal that the socket may end up in the TIME_WAIT
> > > > state after the response has been fully processed.
> > > >
> > > > Wire / context log should help find out why the connection needs to be
> > > > closed.
> > > >
> > > > http://hc.apache.org/httpcomponents-client-4.3.x/logging.html
> > > >
> > > > Oleg
> > > >
> > > > >
> > > > > 2014-01-29 Oleg Kalnichevski <ol...@apache.org>
> > > > >
> > > > > > On Tue, 2014-01-28 at 18:00 +0100, Thomas Boniface wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I am using an http async client to contact several endpoints in
> > a row
> > > > > > with
> > > > > > > the same process. In the context of my application I want to
> > keep the
> > > > > > > global process under a certain time. Sometimes it happens some
> > of the
> > > > > > > executes I triggered using the client did not respond before
> > what I
> > > > > > > consider to be a reasonable time.
> > > > > > >
> > > > > > > In such a case I used to call cancel on the Future object
> > returned
> > > > by the
> > > > > > > execute in order to free the socket used by this execute as soon
> > as
> > > > > > > possible (as I don't need the response anymore). The thing is it
> > > > appears
> > > > > > > that the socket is closed instead of being put back in the pool
> > when
> > > > I
> > > > > > call
> > > > > > > the cancel (The socket appears in TIME_WAIT state when I use
> > netstat
> > > > > > > whereas when there is no timeout the socket appears as
> > ESTABLISHED).
> > > > > > >
> > > > > > > Is this an expected behavior ?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Thomas
> > > > > >
> > > > > > Thomas,
> > > > > >
> > > > > > What version of HttpAsyncClient are you using?
> > > > > >
> > > > > > Oleg
> > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > > > > For additional commands, e-mail:
> > httpclient-users-help@hc.apache.org
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > > >
> > > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Cancel and socket state
Posted by Thomas Boniface <th...@stickyads.tv>.
I can't get my hand on the snapshot can you give a pointer ?
It doesn't appear to be available at:
https://repository.apache.org/content/repositories/snapshots/org/apache/httpcomponents/
Nor I can download it using maven: mvn
org.apache.maven.plugins:maven-dependency-plugin:2.4:get
-DartifactId=httpcomponents-asyncclient -DgroupId=org.apache.httpcomponents
-Dversion=4.0.1-SNAPSHOT
Thanks
2014-01-29 Oleg Kalnichevski <ol...@apache.org>
> On Wed, 2014-01-29 at 14:21 +0100, Thomas Boniface wrote:
> > Hi Oleg,
> >
> > Here is a log with the wire and context log for the behavior I described
> > before. I obfuscated business related details in the log but most of the
> > interesting things should be there.
> >
> > Thanks,
> > Thomas
> >
> >
>
> For some reason the client considers the connection to be an
> inconsistent state and drops it. I cannot figure out why just by looking
> at the log.
>
> Could you please do the following: upgrade to the latest 4.0.1-SNAPSHOT,
> re-run the test and re-post the log as well as let me know exactly how
> your application cancels the request?
>
> Oleg
>
> >
> > 2014-01-29 Oleg Kalnichevski <ol...@apache.org>
> >
> > > On Wed, 2014-01-29 at 10:42 +0100, Thomas Boniface wrote:
> > > > Hi,
> > > >
> > > > I am using the httpasyncclient 4.0.
> > > >
> > > > Thomas
> > > >
> > >
> > > Then, things do not quite add up. If one cancels the result future,
> this
> > > should have no impact on the ongoing request execution. The request
> > > still gets fully executed, the response gets fully processed and the
> > > underlying connection gets returned back to the pool (provided it can
> be
> > > kept alive). The future is simply considered done and will receive no
> > > result notification.
> > >
> > > Please note though that connections cannot be kept alive in some cases.
> > > So, it is perfectly normal that the socket may end up in the TIME_WAIT
> > > state after the response has been fully processed.
> > >
> > > Wire / context log should help find out why the connection needs to be
> > > closed.
> > >
> > > http://hc.apache.org/httpcomponents-client-4.3.x/logging.html
> > >
> > > Oleg
> > >
> > > >
> > > > 2014-01-29 Oleg Kalnichevski <ol...@apache.org>
> > > >
> > > > > On Tue, 2014-01-28 at 18:00 +0100, Thomas Boniface wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I am using an http async client to contact several endpoints in
> a row
> > > > > with
> > > > > > the same process. In the context of my application I want to
> keep the
> > > > > > global process under a certain time. Sometimes it happens some
> of the
> > > > > > executes I triggered using the client did not respond before
> what I
> > > > > > consider to be a reasonable time.
> > > > > >
> > > > > > In such a case I used to call cancel on the Future object
> returned
> > > by the
> > > > > > execute in order to free the socket used by this execute as soon
> as
> > > > > > possible (as I don't need the response anymore). The thing is it
> > > appears
> > > > > > that the socket is closed instead of being put back in the pool
> when
> > > I
> > > > > call
> > > > > > the cancel (The socket appears in TIME_WAIT state when I use
> netstat
> > > > > > whereas when there is no timeout the socket appears as
> ESTABLISHED).
> > > > > >
> > > > > > Is this an expected behavior ?
> > > > > >
> > > > > > Thanks,
> > > > > > Thomas
> > > > >
> > > > > Thomas,
> > > > >
> > > > > What version of HttpAsyncClient are you using?
> > > > >
> > > > > Oleg
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > > > For additional commands, e-mail:
> httpclient-users-help@hc.apache.org
> > > > >
> > > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: Cancel and socket state
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2014-01-29 at 14:21 +0100, Thomas Boniface wrote:
> Hi Oleg,
>
> Here is a log with the wire and context log for the behavior I described
> before. I obfuscated business related details in the log but most of the
> interesting things should be there.
>
> Thanks,
> Thomas
>
>
For some reason the client considers the connection to be an
inconsistent state and drops it. I cannot figure out why just by looking
at the log.
Could you please do the following: upgrade to the latest 4.0.1-SNAPSHOT,
re-run the test and re-post the log as well as let me know exactly how
your application cancels the request?
Oleg
>
> 2014-01-29 Oleg Kalnichevski <ol...@apache.org>
>
> > On Wed, 2014-01-29 at 10:42 +0100, Thomas Boniface wrote:
> > > Hi,
> > >
> > > I am using the httpasyncclient 4.0.
> > >
> > > Thomas
> > >
> >
> > Then, things do not quite add up. If one cancels the result future, this
> > should have no impact on the ongoing request execution. The request
> > still gets fully executed, the response gets fully processed and the
> > underlying connection gets returned back to the pool (provided it can be
> > kept alive). The future is simply considered done and will receive no
> > result notification.
> >
> > Please note though that connections cannot be kept alive in some cases.
> > So, it is perfectly normal that the socket may end up in the TIME_WAIT
> > state after the response has been fully processed.
> >
> > Wire / context log should help find out why the connection needs to be
> > closed.
> >
> > http://hc.apache.org/httpcomponents-client-4.3.x/logging.html
> >
> > Oleg
> >
> > >
> > > 2014-01-29 Oleg Kalnichevski <ol...@apache.org>
> > >
> > > > On Tue, 2014-01-28 at 18:00 +0100, Thomas Boniface wrote:
> > > > > Hi,
> > > > >
> > > > > I am using an http async client to contact several endpoints in a row
> > > > with
> > > > > the same process. In the context of my application I want to keep the
> > > > > global process under a certain time. Sometimes it happens some of the
> > > > > executes I triggered using the client did not respond before what I
> > > > > consider to be a reasonable time.
> > > > >
> > > > > In such a case I used to call cancel on the Future object returned
> > by the
> > > > > execute in order to free the socket used by this execute as soon as
> > > > > possible (as I don't need the response anymore). The thing is it
> > appears
> > > > > that the socket is closed instead of being put back in the pool when
> > I
> > > > call
> > > > > the cancel (The socket appears in TIME_WAIT state when I use netstat
> > > > > whereas when there is no timeout the socket appears as ESTABLISHED).
> > > > >
> > > > > Is this an expected behavior ?
> > > > >
> > > > > Thanks,
> > > > > Thomas
> > > >
> > > > Thomas,
> > > >
> > > > What version of HttpAsyncClient are you using?
> > > >
> > > > Oleg
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > > >
> > > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Cancel and socket state
Posted by Thomas Boniface <th...@stickyads.tv>.
Here is the log I forgot to attach on my previous mail.
Thomas
2014-01-29 Thomas Boniface <th...@stickyads.tv>
> Hi Oleg,
>
> Here is a log with the wire and context log for the behavior I described
> before. I obfuscated business related details in the log but most of the
> interesting things should be there.
>
> Thanks,
> Thomas
>
>
>
> 2014-01-29 Oleg Kalnichevski <ol...@apache.org>
>
>> On Wed, 2014-01-29 at 10:42 +0100, Thomas Boniface wrote:
>> > Hi,
>> >
>> > I am using the httpasyncclient 4.0.
>> >
>> > Thomas
>> >
>>
>> Then, things do not quite add up. If one cancels the result future, this
>> should have no impact on the ongoing request execution. The request
>> still gets fully executed, the response gets fully processed and the
>> underlying connection gets returned back to the pool (provided it can be
>> kept alive). The future is simply considered done and will receive no
>> result notification.
>>
>> Please note though that connections cannot be kept alive in some cases.
>> So, it is perfectly normal that the socket may end up in the TIME_WAIT
>> state after the response has been fully processed.
>>
>> Wire / context log should help find out why the connection needs to be
>> closed.
>>
>> http://hc.apache.org/httpcomponents-client-4.3.x/logging.html
>>
>> Oleg
>>
>> >
>> > 2014-01-29 Oleg Kalnichevski <ol...@apache.org>
>> >
>> > > On Tue, 2014-01-28 at 18:00 +0100, Thomas Boniface wrote:
>> > > > Hi,
>> > > >
>> > > > I am using an http async client to contact several endpoints in a
>> row
>> > > with
>> > > > the same process. In the context of my application I want to keep
>> the
>> > > > global process under a certain time. Sometimes it happens some of
>> the
>> > > > executes I triggered using the client did not respond before what I
>> > > > consider to be a reasonable time.
>> > > >
>> > > > In such a case I used to call cancel on the Future object returned
>> by the
>> > > > execute in order to free the socket used by this execute as soon as
>> > > > possible (as I don't need the response anymore). The thing is it
>> appears
>> > > > that the socket is closed instead of being put back in the pool
>> when I
>> > > call
>> > > > the cancel (The socket appears in TIME_WAIT state when I use netstat
>> > > > whereas when there is no timeout the socket appears as ESTABLISHED).
>> > > >
>> > > > Is this an expected behavior ?
>> > > >
>> > > > Thanks,
>> > > > Thomas
>> > >
>> > > Thomas,
>> > >
>> > > What version of HttpAsyncClient are you using?
>> > >
>> > > Oleg
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
>> > >
>> > >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>
>>
>
Re: Cancel and socket state
Posted by Thomas Boniface <th...@stickyads.tv>.
Hi Oleg,
Here is a log with the wire and context log for the behavior I described
before. I obfuscated business related details in the log but most of the
interesting things should be there.
Thanks,
Thomas
2014-01-29 Oleg Kalnichevski <ol...@apache.org>
> On Wed, 2014-01-29 at 10:42 +0100, Thomas Boniface wrote:
> > Hi,
> >
> > I am using the httpasyncclient 4.0.
> >
> > Thomas
> >
>
> Then, things do not quite add up. If one cancels the result future, this
> should have no impact on the ongoing request execution. The request
> still gets fully executed, the response gets fully processed and the
> underlying connection gets returned back to the pool (provided it can be
> kept alive). The future is simply considered done and will receive no
> result notification.
>
> Please note though that connections cannot be kept alive in some cases.
> So, it is perfectly normal that the socket may end up in the TIME_WAIT
> state after the response has been fully processed.
>
> Wire / context log should help find out why the connection needs to be
> closed.
>
> http://hc.apache.org/httpcomponents-client-4.3.x/logging.html
>
> Oleg
>
> >
> > 2014-01-29 Oleg Kalnichevski <ol...@apache.org>
> >
> > > On Tue, 2014-01-28 at 18:00 +0100, Thomas Boniface wrote:
> > > > Hi,
> > > >
> > > > I am using an http async client to contact several endpoints in a row
> > > with
> > > > the same process. In the context of my application I want to keep the
> > > > global process under a certain time. Sometimes it happens some of the
> > > > executes I triggered using the client did not respond before what I
> > > > consider to be a reasonable time.
> > > >
> > > > In such a case I used to call cancel on the Future object returned
> by the
> > > > execute in order to free the socket used by this execute as soon as
> > > > possible (as I don't need the response anymore). The thing is it
> appears
> > > > that the socket is closed instead of being put back in the pool when
> I
> > > call
> > > > the cancel (The socket appears in TIME_WAIT state when I use netstat
> > > > whereas when there is no timeout the socket appears as ESTABLISHED).
> > > >
> > > > Is this an expected behavior ?
> > > >
> > > > Thanks,
> > > > Thomas
> > >
> > > Thomas,
> > >
> > > What version of HttpAsyncClient are you using?
> > >
> > > Oleg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: Cancel and socket state
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2014-01-29 at 10:42 +0100, Thomas Boniface wrote:
> Hi,
>
> I am using the httpasyncclient 4.0.
>
> Thomas
>
Then, things do not quite add up. If one cancels the result future, this
should have no impact on the ongoing request execution. The request
still gets fully executed, the response gets fully processed and the
underlying connection gets returned back to the pool (provided it can be
kept alive). The future is simply considered done and will receive no
result notification.
Please note though that connections cannot be kept alive in some cases.
So, it is perfectly normal that the socket may end up in the TIME_WAIT
state after the response has been fully processed.
Wire / context log should help find out why the connection needs to be
closed.
http://hc.apache.org/httpcomponents-client-4.3.x/logging.html
Oleg
>
> 2014-01-29 Oleg Kalnichevski <ol...@apache.org>
>
> > On Tue, 2014-01-28 at 18:00 +0100, Thomas Boniface wrote:
> > > Hi,
> > >
> > > I am using an http async client to contact several endpoints in a row
> > with
> > > the same process. In the context of my application I want to keep the
> > > global process under a certain time. Sometimes it happens some of the
> > > executes I triggered using the client did not respond before what I
> > > consider to be a reasonable time.
> > >
> > > In such a case I used to call cancel on the Future object returned by the
> > > execute in order to free the socket used by this execute as soon as
> > > possible (as I don't need the response anymore). The thing is it appears
> > > that the socket is closed instead of being put back in the pool when I
> > call
> > > the cancel (The socket appears in TIME_WAIT state when I use netstat
> > > whereas when there is no timeout the socket appears as ESTABLISHED).
> > >
> > > Is this an expected behavior ?
> > >
> > > Thanks,
> > > Thomas
> >
> > Thomas,
> >
> > What version of HttpAsyncClient are you using?
> >
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Cancel and socket state
Posted by Thomas Boniface <th...@stickyads.tv>.
Hi,
I am using the httpasyncclient 4.0.
Thomas
2014-01-29 Oleg Kalnichevski <ol...@apache.org>
> On Tue, 2014-01-28 at 18:00 +0100, Thomas Boniface wrote:
> > Hi,
> >
> > I am using an http async client to contact several endpoints in a row
> with
> > the same process. In the context of my application I want to keep the
> > global process under a certain time. Sometimes it happens some of the
> > executes I triggered using the client did not respond before what I
> > consider to be a reasonable time.
> >
> > In such a case I used to call cancel on the Future object returned by the
> > execute in order to free the socket used by this execute as soon as
> > possible (as I don't need the response anymore). The thing is it appears
> > that the socket is closed instead of being put back in the pool when I
> call
> > the cancel (The socket appears in TIME_WAIT state when I use netstat
> > whereas when there is no timeout the socket appears as ESTABLISHED).
> >
> > Is this an expected behavior ?
> >
> > Thanks,
> > Thomas
>
> Thomas,
>
> What version of HttpAsyncClient are you using?
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: Cancel and socket state
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2014-01-28 at 18:00 +0100, Thomas Boniface wrote:
> Hi,
>
> I am using an http async client to contact several endpoints in a row with
> the same process. In the context of my application I want to keep the
> global process under a certain time. Sometimes it happens some of the
> executes I triggered using the client did not respond before what I
> consider to be a reasonable time.
>
> In such a case I used to call cancel on the Future object returned by the
> execute in order to free the socket used by this execute as soon as
> possible (as I don't need the response anymore). The thing is it appears
> that the socket is closed instead of being put back in the pool when I call
> the cancel (The socket appears in TIME_WAIT state when I use netstat
> whereas when there is no timeout the socket appears as ESTABLISHED).
>
> Is this an expected behavior ?
>
> Thanks,
> Thomas
Thomas,
What version of HttpAsyncClient are you using?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org