-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[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.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you considered using an Thread.UncaughtExceptionHandler instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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