Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JMeter 5.6 - ThreadGroups are running endlessly in non-gui mode #6008

Closed
dgetzlaf opened this issue Jun 26, 2023 · 6 comments · Fixed by #6011
Closed

JMeter 5.6 - ThreadGroups are running endlessly in non-gui mode #6008

dgetzlaf opened this issue Jun 26, 2023 · 6 comments · Fixed by #6011
Milestone

Comments

@dgetzlaf
Copy link
Contributor

Expected behavior

In gui mode, JMeter acts as always.
In non-gui mode JMeter runs all Thread Groups endlessly, when there is no specified Thread lifetime.

JMeter was used to run the number of configured Loops - even without a specified Thread lifetime.

image

Also there was a Property in the JMX beneath the ThreadGroup

<elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller">
    <boolProp name="LoopController.continue_forever">false</boolProp>
    <stringProp name="LoopController.loops">1</stringProp>
</elementProp>

Actual behavior

Since JMeter 5.6 the ThreadGroups without a specified Thread lifetime run endlessly.
Also the property in the JMX beneath the ThreadGroup is missing

    <boolProp name="LoopController.continue_forever">false</boolProp>

Steps to reproduce the problem

Open a TestPlan from JMeter 5.5 with JMeter 5.6, save it and review the difference.

Otherwise use this test plan non-stopping-threads-jmeter-5.6.jmx.txt

run in gui mode -> should execute...
.. the setUp Thread Group once
..the Thread Group 4 times

  • run in non-gui mode <path-to-jmeter-5.6>\jmeter.bat -t non-stopping-threads-jmeter-5.6.jmx -l jmeter.log -n
  • tail the jmeter.log
  • see that the setUp Thread Group is not stopping (consecutive printing of 'Should exist only once')
  • abort the test execution

JMeter Version

5.6

Java Version

openjdk version "17.0.7" 2023-04-18 LTS OpenJDK Runtime Environment (build 17.0.7+7-LTS) OpenJDK 64-Bit Server VM (build 17.0.7+7-LTS, mixed mode, sharing)

OS Version

Microsoft Windows [Version 10.0.19045.3086]

@vlsi
Copy link
Collaborator

vlsi commented Jun 26, 2023

Since JMeter 5.6 the ThreadGroups without a specified Thread lifetime run endlessly.
Also the property in the JMX beneath the ThreadGroup is missing

The default value is indeed not saved.
However, it should be loaded as "default".

@vlsi vlsi removed the to-triage label Jun 26, 2023
@vlsi vlsi added this to the 5.6.1 milestone Jun 26, 2023
vlsi added a commit to vlsi/jmeter that referenced this issue Jun 27, 2023
…itializing in the constructor

Previously LoopController initialized continue_forever=true in the constructor,
however, and ThreadGroup.setMainController flipped the value to false.

It caused inconsistency since non-GUI launch does not call ThreadGroup.setMainController.

Using default=true enables to treat "false" as non-standard, so =false is saved
t the jmx, and it gets loaded in non-GUI as well.

Fixes apache#6008
vlsi added a commit to vlsi/jmeter that referenced this issue Jun 27, 2023
…itializing in the constructor

Previously LoopController initialized continue_forever=true in the constructor,
however, and ThreadGroup.setMainController flipped the value to false.

It caused inconsistency since non-GUI launch does not call ThreadGroup.setMainController.

Using default=true enables to treat "false" as non-standard, so =false is saved
t the jmx, and it gets loaded in non-GUI as well.

Fixes apache#6008
@sginsbourg
Copy link

sginsbourg commented Jun 27, 2023 via email

vlsi added a commit to vlsi/jmeter that referenced this issue Jun 27, 2023
…itializing in the constructor

Previously LoopController initialized continue_forever=true in the constructor,
however, and ThreadGroup.setMainController flipped the value to false.

It caused inconsistency since non-GUI launch does not call ThreadGroup.setMainController.

Using default=true enables to treat "false" as non-standard, so =false is saved
t the jmx, and it gets loaded in non-GUI as well.

Fixes apache#6008
vlsi added a commit that referenced this issue Jun 28, 2023
…itializing in the constructor

Previously LoopController initialized continue_forever=true in the constructor,
however, and ThreadGroup.setMainController flipped the value to false.

It caused inconsistency since non-GUI launch does not call ThreadGroup.setMainController.

Using default=true enables to treat "false" as non-standard, so =false is saved
t the jmx, and it gets loaded in non-GUI as well.

Fixes #6008
@vlsi vlsi pinned this issue Jun 29, 2023
@mauritz-lovgren
Copy link

Is there a workaround to this issue before 5.6.1 comes out? Such as setting a value to the LoopController attribute to make it stop after executing the tests just like it does in UI mode?

@vlsi
Copy link
Collaborator

vlsi commented Jun 29, 2023

The workaround is to edit .jmx manually so you add <boolProp name="LoopController.continue_forever">false</boolProp> under <elementProp name="ThreadGroup.main_controller".

Unfortunately, it will disappear every time you save the file in JMeter 5.6.

An alternative option is to use a different thread group. For instance, Open Model Thread Group.

@mauritz-lovgren
Copy link

The workaround is to edit .jmx manually so you add <boolProp name="LoopController.continue_forever">false</boolProp> under <elementProp name="ThreadGroup.main_controller".

Unfortunately, it will disappear every time you save the file in JMeter 5.6.

An alternative option is to use a different thread group. For instance, Open Model Thread Group.

Thank you, that will do the trick for us. We store the jmx file in GitHub, so we can add this manually to make the automated tests (that run in non-UI mode) work again until 5.6.1 is out! Thanks!

@vlsi
Copy link
Collaborator

vlsi commented Jul 10, 2023

5.6.1 is released, enjoy

@vlsi vlsi unpinned this issue Jan 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants