I had noticed the large number of threads, and was thinking that the code should probably be replaced. (Perhaps with Jakarta-Commons-Pool?) I was hoping to find a quick fix that might get around this current problem, and then replace the pool sometime during the next release cycle. I don't know whether or not that "quick fix" will be possible...hopefully the additional information I requested will help in figuring that out.
But perhaps I should ask one more question of Serge: How critical is this? Are you hoping for a solution right away, or can it wait awhile? If it can wait a bit, I'll probably just replace the connection pool rather than trying to fix the existing one. If you need a quick fix, I'll look at the current implementation a bit more -- but no guarantees that I'll be able to actually fix it...if it's a lot of effort then I would rather invest it in putting in the new implementation.
Jeremy
[EMAIL PROTECTED] wrote:
One problem with JMeter's connection pool is that it spawn's lots of new threads. Every connection that needs to be renewed gets a new thread to do it in. this is very inappropriate given the rest of JMeter's architecture. It may be that after thousands of times, the OS/JVM balks.
I would not consider a solution that involved modifying the current pooling code. Instead, it should be replaced with something new.
-Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
