jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enric Jaen <>
Subject Re: AccessLogSampler & Bug 53748
Date Thu, 20 Jun 2013 06:58:12 GMT
However, http sessions must  be considered, so a kind of preprocessing is still needed to
know in advance when the thread can be closed.

 De: Enric Jaen <>
Para: "" <> 
Enviado: Jueves 20 de junio de 2013 6:59
Asunto: Re: Rv: AccessLogSampler & Bug 53748

I see. Right, I didn't realize of the file handler problem.  So yes,  an approach like the
one you proposed is needed. An approach where and entity reads the log file an creates the
threads at the corresponding log rate.  

De: sebb <>
Para:; Enric Jaen <> 
Enviado: Jueves 20 de junio de 2013 0:14
Asunto: Re: Rv: AccessLogSampler & Bug 53748

On 19 June 2013 20:10, Enric Jaen <> wrote:
> (sorry if you receive this mail duplicated,  I am having problems sending in this mailing
> Hello,
> I see some confusion. With respect the concern that the OS can run out of file handles,
let me clarify that this sampler doesn't need a  different file per thread: The generator
reads the access log and creates one new access log file. This new file is ordered by IP,
and each thread knows its correspoding OFFSET inside the file.

Sorry, I realise that "file handle" was ambiguous.

I did not mean entries in the the file system table on disk or in
memory, I meant the handle to the file used by Java.
It will still use the same number of open file handles (e,g,
FileInputStream plus supporting FD etc.) within the JVM.
Though perhaps some resources can be shared by the JVM if all the
files are the same, so it might be slightly cheaper than individual
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message