On 9 October 2011 10:50, Philippe Mouawad <philippe.moua...@gmail.com> wrote: > Hello Sebb, > Regarding the cloning of a Sampler you mention in you mail "Unfortunately, > cloning the sampler is not easy.", > could you give more explanations on why it is not easy to clone the sampler > ?
It's easy to call clone on the sampler. However, the fields are not all simple objects; it's not clear if nested objects in collections etc will clone properly. However, it's worth a try to see it it works, because it would be the simplest solution to the mutable fields. Still need to check things like http connections to make sure they are being used correctly and cleared when the new thread exits. The JMeter design allows samplers to rely on events such as TestStarted etc. These won't automatically be generated for the mini-threads used for concurrent downloads. Or perhaps we could take the concurrent download setting into account when creating the initial httpclient instances (i.e. make it part of the key) so we can generate enough pool entries. The mini-threads would then use the parent pool, and the parent can be responsible for tidying up at end of run. But then, what about connection close? Would that need to be delayed until subsamples had completed? As I wrote earlier, the JMeter design is predicated on single-threaded samplers, so changes here need careful consideration. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
