https://issues.apache.org/bugzilla/show_bug.cgi?id=47886
Flick <cflic...@novator.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #2 from Flick <cflic...@novator.com> 2009-09-22 08:03:09 PDT ---
The patch was just an example of what I hacked together to get our environment
working. In no way is it intended to be elegant, just a sample. I am
unfamiliar with the jmeter code base in its entirety and all the various
samplers, but I think it is still reasonable to have something like this
supported. The thread pool i used doesn't fix the size at the configured
amount, that's just how many are kept in the pool even when idle. If the
configured sampler had a high number of threads needing to execute
simultaneously, the pool would create more. It would still help my situation
where i have 20K+ users executing over a 60 minute period resulting in only
about 10-60 concurrent threads depending on response times.
In my sample, the state is maintained in the JMeterThread object, not the
Thread, and the context still uses ThreadLocal since a given Thread from the
thread pool is only used by one JMeterThread at a time.
Also, graceful shutdown could still be supported.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org
