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 <[email protected]> Para: [email protected]; Enric Jaen <[email protected]> Enviado: Jueves 20 de junio de 2013 0:14 Asunto: Re: Rv: AccessLogSampler & Bug 53748 On 19 June 2013 20:10, Enric Jaen <[email protected]> wrote: > > > (sorry if you receive this mail duplicated, I am having problems sending in > this mailing list) > > 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 files.
