jakarta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
Date Sun, 09 Oct 2011 11:14:35 GMT
On 9 October 2011 10:50, Philippe Mouawad <philippe.mouawad@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-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org


Mime
View raw message