Forum Discussion
tdrury
11 years agoContributor
It's a 10 thread, simple strategy which is configured for 1 run per thread.
Maybe I should try to explain our test (and our app) a bit more. Our app controls factory floors. Imagine you have a 10 step process to build a widget: Step 1 -> Step 2 -> Step 3 -> ... -> Step 10 and each steps adds a few more components on the widget until you have a completed widget after Step 10.
The guy at Step 2 can't do anything until the guy at Step 1 hands him a partially completed widget. Our test is written so that each thread is acting as a user at a step (10 steps=10 users, therefore 10 threads). The test case we run first checks to see if there is a widget available to process and, if not, sleeps 100ms then checks again. If there is a widget ready to process, it adds a few bits to it, then checks to see if all widgets (we tell it to build 5 widgets) have finished that Step. If not, it goes back to the beginning of the test. If it is finished, the test case ends and that thread is finished.
If, for example, something really bad happens at Step 2, I wanted to kill the whole load test. But calling fail() within the test case finished thread 2, but thread 3 (at step 3) is waiting for widgets from Step 2 and will never get them. So that thread is never cancelled and soapUI hangs.
Maybe I should try to explain our test (and our app) a bit more. Our app controls factory floors. Imagine you have a 10 step process to build a widget: Step 1 -> Step 2 -> Step 3 -> ... -> Step 10 and each steps adds a few more components on the widget until you have a completed widget after Step 10.
The guy at Step 2 can't do anything until the guy at Step 1 hands him a partially completed widget. Our test is written so that each thread is acting as a user at a step (10 steps=10 users, therefore 10 threads). The test case we run first checks to see if there is a widget available to process and, if not, sleeps 100ms then checks again. If there is a widget ready to process, it adds a few bits to it, then checks to see if all widgets (we tell it to build 5 widgets) have finished that Step. If not, it goes back to the beginning of the test. If it is finished, the test case ends and that thread is finished.
If, for example, something really bad happens at Step 2, I wanted to kill the whole load test. But calling fail() within the test case finished thread 2, but thread 3 (at step 3) is waiting for widgets from Step 2 and will never get them. So that thread is never cancelled and soapUI hangs.
Related Content
- 5 years agovpetrou
- 10 years agoRyan_Moran
- 9 years agojstrauss64