On Sun, Oct 9, 2011 at 1:14 PM, sebb <seb...@gmail.com> wrote: > 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. > > I start tests it seems OK, CollectionProperty elements are cloned (Note that I clone CookieManager if it's not null), HTTPAbstractImpl are recreated for cloned sampler.
I noticed that after clone , threadContext is null, do you see a reason why it should be copied from parent ? I think it's OK if it's null because we don't need any variables just to download > 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. > > It seems right . > 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. > I am not sure I undestand what you meen but if it's about creating Executor threads when JMeterThread starts and stopping them, I think it is a good one , because in current implementation, we start/stop Threads which has some performance cost. But this may have bigger code impacts and there is the issue of different conc pool size. For now, if pool is 5, we have 5 HttpClient created and they are destroyed when Executor is shutdown. > > But then, what about connection close? Would that need to be delayed > until subsamples had completed? > Are you talking about closeThreadLocalConnections() or something else ? > > 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 > > -- Cordialement. Philippe Mouawad.