Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jmeter.apache.org
Message-ID: <530D9849.5080501@apache.org>
Date: Wed, 26 Feb 2014 07:31:21 +0000
From: Milamber <milamber@apache.org>
Organization: Apache Software Fondation
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22
MIME-Version: 1.0
To: dev@jmeter.apache.org
Subject: Re: Idle connection timeout where Keep-Alive is not sent
References: 
 <CAOGo0VZqUo-PkP+6iV0PvyqNNxA-rUYx4Xq=H0B7rfNrxOzjdQ@mail.gmail.com>
In-Reply-To: 
 <CAOGo0VZqUo-PkP+6iV0PvyqNNxA-rUYx4Xq=H0B7rfNrxOzjdQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


Le 26/02/2014 02:21, sebb a ecrit :
> HC4 allows one to provide a ConnectionKeepAliveStrategy which allows
> one to provide a time-to-live (TTL) for the connection, based on the
> HttpResponse and the HttpContext
>
> There is a default implementation which uses the Keep-Alive header to
> calculate the time.
>
> So we can subclass that, and provide our own calculation if the
> default one does not find the header.
>
> That's easy, and I've tried it.
>
> What is not so obvious is how to specify which URLs need what idle timeouts.
> The simplest would be to use a property to apply a timeout to any
> requests that don't return the Keep-Alive header, but that may be too
> crude in general, as it would enforce timeouts on every host.
>
> However it would be a good proof of concept that could be used against S3 etc.
>
> We could add an idle timeout field to the HttpSampler GUIbut that
> might be tedious to maintain. Adding it to the Http Defaults would
> work provided that there was a single value that suited all the Http
> requests in scope (not much better than using a global property).
>
> Would that be sufficient?

Yes seems sufficient in a first time (have a property or idle timeout 
field to the Http Defautls GUI).

> Or do we need a way to specify the timeout on a per-host basis?
> Maybe a list of hostnames and timeouts?
>
> Any other bright ideas?
>
> I propose to implement the single property method (but document it as
> subject to change) so that it can be tested in earnest.


+1.

Thanks

Milamber

>
> Then we can see how it might need to be extended.
>