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>
> > Hello Sebb,
> > Regarding the cloning of a Sampler you mention in you mail
> > cloning the sampler is not easy.",
> > could you give more explanations on why it is not easy to clone the
> > ?
> 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
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