https://bz.apache.org/bugzilla/show_bug.cgi?id=65031
--- Comment #4 from rabele...@gmail.com --- Hello, I think 3rd option has a good balance, but maybe something needs to be added to documentation about the first thread, and the special case when you have only 1 thread. For example, by default thread group is initialized with 1 thread and 1 second ramp up, but that ramp up will never be applied, maybe 0 would be a more adequate value in such case, but changing the default value also makes test plans that change the thread group number to no longer ramp up by default. I think the 2nd option is simpler and potentially more intuitive alternative, but has the issue you mention (test not starting right away, unless use 0 and start all threads at the beginning of the test). Another option (we might call it 3b) might be to allow the user to set the behavior through a JMeter property, eg: START_FIRST_THREAD_IMMEDIATELY (it could be initially set to false, and in later version of JMeter, with proper warning to users, change it's default value to true). I personally would avoid using JMeter properties because they look like hidden features, add to the general complexity of the app (you have another "IF" in your logic), and in many cases are under documented (you have to dig into code to find the existence of such properties). A final option (that is aligned with your 1st option, and might call it 1b) is just changing documentation to reflect current behavior. That would avoid other users potentially reporting this issue in the feature, avoid changes in logic for users that have already implemented logic based on current behavior, but would still leave some inconsistency for users using the UI and not checking documentation. Best regards, and thank you to look into this. -- You are receiving this mail because: You are the assignee for the bug.
