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 "KARR, DAVID (ATTSI)" <dk...@att.com> on 2010/07/29 17:31:05 UTC
Best strategy to terminate an HttpClient (3.0.1) connection from a background thread?
If I had a background task that was monitoring certain conditions, and
it had a handle to an HttpClient object, or perhaps the Method object,
where the Method was still executing, what would be the cleanest way to
force terminate the connection from the background task, such that the
method execution would get a reasonable exception that could be
interpreted as either a timeout or a force disconnect? I see the
"HttpMethodBase.abort()" method. Would this be reasonable?
For a little more background, I'm considering this to implement a "hard
timeout" on HttpClient connections, as the socket timeout doesn't really
do that. When the system is under high load, we find that connections
go well over what we wanted as the "time limit" for the connection.
We've concluded that we'd rather terminate over-long connections, even
if they would have normally succeeded, as we think it might help overall
scalability.
Even if I could have the background task terminate the connection
cleanly, I'm not certain this will help our situation, and determining
whether it will help before it gets to production will be difficult.
When the system is under high load, things tend to be a little chaotic
:) . I might find that my background task doesn't get enough time to
run, or it might end up making the other tasks take longer.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
RE: Best strategy to terminate an HttpClient (3.0.1) connection
from a background thread?
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2010-08-01 at 09:34 -0700, KARR, DAVID (ATTSI) wrote:
> > -----Original Message-----
> > From: Oleg Kalnichevski [mailto:olegk@apache.org]
> > Sent: Sunday, August 01, 2010 4:47 AM
> > To: HttpClient User Discussion
> > Subject: Re: Best strategy to terminate an HttpClient (3.0.1)
> > connection from a background thread?
> >
> > On Thu, 2010-07-29 at 08:31 -0700, KARR, DAVID (ATTSI) wrote:
> > > If I had a background task that was monitoring certain conditions,
> > and
> > > it had a handle to an HttpClient object, or perhaps the Method
> > object,
> > > where the Method was still executing, what would be the cleanest way
> > to
> > > force terminate the connection from the background task, such that
> > the
> > > method execution would get a reasonable exception that could be
> > > interpreted as either a timeout or a force disconnect? I see the
> > > "HttpMethodBase.abort()" method. Would this be reasonable?
> > >
> >
> > Yes, it would.
>
> Thanks for the confirmation.
>
> > > For a little more background, I'm considering this to implement a
> > "hard
> > > timeout" on HttpClient connections, as the socket timeout doesn't
> > really
> > > do that. When the system is under high load, we find that
> > connections
> > > go well over what we wanted as the "time limit" for the connection.
> > > We've concluded that we'd rather terminate over-long connections,
> > even
> > > if they would have normally succeeded, as we think it might help
> > overall
> > > scalability.
> > >
> >
> > If your main objective is scalability I am not sure if this approach is
> > going to help especially when using SSL connections.
>
> Neither am I. That's why I'm going to set it up to be turned on or off or tuned dynamically at runtime, so I can easily measure it's behavior during expected peak periods.
>
Makes good sense.
> Why specifically do you think this won't help for SSL connections?
SSL connections are expensive to set up. Under load it is likely to be
cheaper to reuse existing connections than to establish new ones.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
RE: Best strategy to terminate an HttpClient (3.0.1) connection from a background thread?
Posted by "KARR, DAVID (ATTSI)" <dk...@att.com>.
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Sunday, August 01, 2010 4:47 AM
> To: HttpClient User Discussion
> Subject: Re: Best strategy to terminate an HttpClient (3.0.1)
> connection from a background thread?
>
> On Thu, 2010-07-29 at 08:31 -0700, KARR, DAVID (ATTSI) wrote:
> > If I had a background task that was monitoring certain conditions,
> and
> > it had a handle to an HttpClient object, or perhaps the Method
> object,
> > where the Method was still executing, what would be the cleanest way
> to
> > force terminate the connection from the background task, such that
> the
> > method execution would get a reasonable exception that could be
> > interpreted as either a timeout or a force disconnect? I see the
> > "HttpMethodBase.abort()" method. Would this be reasonable?
> >
>
> Yes, it would.
Thanks for the confirmation.
> > For a little more background, I'm considering this to implement a
> "hard
> > timeout" on HttpClient connections, as the socket timeout doesn't
> really
> > do that. When the system is under high load, we find that
> connections
> > go well over what we wanted as the "time limit" for the connection.
> > We've concluded that we'd rather terminate over-long connections,
> even
> > if they would have normally succeeded, as we think it might help
> overall
> > scalability.
> >
>
> If your main objective is scalability I am not sure if this approach is
> going to help especially when using SSL connections.
Neither am I. That's why I'm going to set it up to be turned on or off or tuned dynamically at runtime, so I can easily measure it's behavior during expected peak periods.
Why specifically do you think this won't help for SSL connections?
Re: Best strategy to terminate an HttpClient (3.0.1) connection
from a background thread?
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2010-07-29 at 08:31 -0700, KARR, DAVID (ATTSI) wrote:
> If I had a background task that was monitoring certain conditions, and
> it had a handle to an HttpClient object, or perhaps the Method object,
> where the Method was still executing, what would be the cleanest way to
> force terminate the connection from the background task, such that the
> method execution would get a reasonable exception that could be
> interpreted as either a timeout or a force disconnect? I see the
> "HttpMethodBase.abort()" method. Would this be reasonable?
>
Yes, it would.
> For a little more background, I'm considering this to implement a "hard
> timeout" on HttpClient connections, as the socket timeout doesn't really
> do that. When the system is under high load, we find that connections
> go well over what we wanted as the "time limit" for the connection.
> We've concluded that we'd rather terminate over-long connections, even
> if they would have normally succeeded, as we think it might help overall
> scalability.
>
If your main objective is scalability I am not sure if this approach is
going to help especially when using SSL connections.
Oleg
> Even if I could have the background task terminate the connection
> cleanly, I'm not certain this will help our situation, and determining
> whether it will help before it gets to production will be difficult.
> When the system is under high load, things tend to be a little chaotic
> :) . I might find that my background task doesn't get enough time to
> run, or it might end up making the other tasks take longer.
>
> ---------------------------------------------------------------------
> 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