hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Handling idle timeout disconnect
Date Fri, 21 Feb 2014 23:13:07 GMT
On Fri, Feb 21, 2014 at 6:07 PM, sebb <sebbaz@gmail.com> wrote:

> Further to the recent email about unexpected behaviour in JMeter when
> staleCheck was disabled, the cause has been determined.
> The problem was caused by a server operating an idle timeout policy,
> but failing to send a Keep-Alive header with the timeout information.
> Thus the HC code did not know that the connection would timeout, and
> tried to re-use it.
> This resulted in an immediate disconnect.
> Since JMeter does not retry by default, this caused the sample to fail.
> I'm wondering whether this scenario should be handled automatically by HC.
> It could in theory happen even with servers that send the Keep-Alive
> header if the server and client ideas of elapsed time are not very
> consistent.
> The idea would be to retry the request IFF the connect immediately
> fails - i.e. before any data has been sent.
> This could not cause a problem with non-idempotent requests, as the
> request would not actually have been sent.
> Does that sound reasonable, or is it something the app developer needs
> to implement in a retry handler?

Additional wrinkles:
- How many times do you retry?
- How long do you wait between retries?


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org

E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message