vlsi opened a new issue, #5966: URL: https://github.com/apache/jmeter/issues/5966
### Use case Currently OMTG might create an unlimited amount of threads threads in case the application processes requests slower than JMeter spawns threads. JMeter might run out of memory since every `JMeterThread` uses a cloned test plan. We should report the error and fail gracefully rather than crash with OutOfMemory. Another use case is to test the system with a limited concurrency level. For instance, the system might have a hard limit on the request concurrency (e.g. 10 concurrent requests maximum), and the users might want to test various load levels. ### Possible solution a) Implement a fixed concurrency limit for OMTG b) Implement variable concurrency limit like the current `rate(...)` in the schedule string: `concurrency(10) rate(10/sec) random_arrivals(10 min)` Open questions - [ ] What should OMTG do in case the concurrency limit is reached? Should it discard a launch immediately? Should it wait for some time for the thread to become available? - [ ] How do we report that certain launches were delayed due to concurrency limit? ### Possible workarounds _No response_ ### JMeter Version 5.5 ### Java Version _No response_ ### OS Version _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jmeter.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
