[66139] Ensure Open Model Thread Group initializes config elements only once - #717
Conversation
0a82bc2 to
5de2d3f
Compare
Codecov Report
@@ Coverage Diff @@
## master #717 +/- ##
============================================
+ Coverage 55.23% 55.32% +0.08%
- Complexity 10381 10393 +12
============================================
Files 1062 1062
Lines 65760 65763 +3
Branches 7533 7534 +1
============================================
+ Hits 36322 36381 +59
+ Misses 26837 26777 -60
- Partials 2601 2605 +4
Continue to review full report at Codecov.
|
FSchumacher
left a comment
There was a problem hiding this comment.
Looks good to me, but note, that I am not really an Kotlin expert.
| import org.junit.Test | ||
| import java.time.Duration | ||
|
|
||
| class OpenModelThreadGroupConfigElementTest : JMeterTestCase(), JMeterSerialTest { |
There was a problem hiding this comment.
Really nice test class.
| * Executor service to execute management tasks like "start test", "stop test". | ||
| * The use of {@link ExecutorService} allows propagating the exception from the threads. | ||
| */ | ||
| private static final ExecutorService EXECUTOR_SERVICE = Executors.newCachedThreadPool(); |
There was a problem hiding this comment.
Have you considered using an Thread.UncaughtExceptionHandler instead?
There was a problem hiding this comment.
I do not think UncaughtExceptionHandler makes things any easier/better. I think EXECUTOR_SERVICE.submit(...) gives exception tracking for free, and we should move away from new Thread anyway.
The main problem here is that StandardJMeterEngine.runTest returns void, and there's no way for the client to detect if the test failed or not.
In the ideal case, StandardJMeterEngine.runTest should return something like Future<...>, so the client could await termination or cancel it, or get the results.
However, the change of runTest to return Future is out of the scope of this PR. In this PR, I added the ability to execute and wait for results from StandardJMeterEngine from unit-test code. So I did the minimal set of changes only.
|
The test keeps failing at Travis. |
9148f9d to
1324f6b
Compare
…lled from concurrent threads
…cond #717 introduced cachedThreadPool in StandardJMeterEngine, and it had 60 seconds inactivity timeout by default. It caused non-GUI tests to wait for the threads to cleanup.
See