I renamed the thread group to "Open Model Thread Group" as it seems to be the best title among the suggestions. I added code comments. Review is welcome. I've no idea why GitHub CI hangs, and I have not explored it yet.
So far there's a request from Philippe regarding Kotlin removal. @Philippe, do you veto the use of Kotlin? I would like to refrain from debates and discussions since most of the discussions are theoretical. I suggest we just try it out and see how it goes. Please do not forget there are features that require Kotlin, so we can hardly "veto the use of Kotlin in JMeter": * Programmatic test plan DSL * Coroutine-based async samplers and virtual users * Jetpack Compose UI I am sure "programmatic test plan DSL" would help a lot for creating test code for JMeter itself. ---- I would finish the following items soon, and then the PR will be ready for merging: * Force thread termination on "schedule finish". I think the last "pause" is not accounted for right now * Add more tests (some of the test use println, and it should not be like that) * Do something with even_arrivals(...). Currently, only random_arrivals is implemented, and I would either postpone even_arrivals to the later releases or implement it now. * Implement "validation mode" (==run thread group with single iteration). By the way, I've got a suggestion that a schedule of "1" should yield "one execution of a single thread" just like in "validation mode". I'm not sure if that is intuitive configuration, however, it more-or-less aligns with the old thread group where you can just set 1 everywhere and get "one sample". Things I would like to postpone for the later releases: * "same user on each iteration" vs "new user on each iteration" * "loop count" * "max threads" Vladimir
