I think the code is ready for review and merge. I am inclined to rename the controller to "Open Model Requests" (see below)
* validation mode works now for openmodel * unit tests for schedule generators are there * even_arrivals is supported as well (for both constant and increasing/decreasing loads) *.e2e tests are missing, however, I'm inclined to add them with a test DSL The key missing bits from my point of view are: * consensus on Kotlin * screenshot for the user manual I have not added the screenshot as there's not much feedback yet. ---- As I thought on "thread limit" more, it might be that "Open Model Thread Group" should be named like "Open Model Virtual User Group". Technically speaking, the users should not care much about the number of (hardware?) threads. For instance, if we use "Loom virtual threads" or "coroutines", then "the number of threads" becomes moot. The end-user-facing properties are: * "max number of concurrent in-flight requests" == max number of active "virtual users" * "max number of open sessions/connections" == total number of "virtual users", including both active and inactive. So it might make sense to remove "Thread Group" from the name and replace it with something else. For instance: * Open Model Requests <-- I am inclined to this one * Open Model Virtual Users WDYT? I inline that "Open Model" should have a knob for "max number of concurrent in-flight requests" (== max request concurrency) It might be that "Open Model" should NOT deal with "sessions/connection pools". So it might be that "same user on each iteration", "different user on each iteration" or even "new user in 30% of iterations" should be configured as a test plan element. For instance: a) Flow Control Action that configures probability for "resetting the user" b) "user pool" configuration element that would borrow a user from a pool, so JMeter could emulate case when user makes a big pause and continues scenarios after 10min of idle time. The thing is that "connection pool", "cookie pool" seem to be way less memory consuming than full JMeter test plan after cloning, so having connection pools would scale better than trying to keep lots of cloned test plans in idle state. Vladimir
