|
|
8/21/2017 12:20:26 PM
possible that if job is killed just before the job gets inside the sync block currently in delayExecution(), it can remain in wait for the full delayStartMs instead of exiting. This is fixed by bringing also the checks for isKilled() into the sync block in delayExecution().
|
8/21/2017 12:13:37 PM
sleeping, replace with more eager waiting
- Add sleep to another place to increase stability
- Extracted common purpose method into a new helper class
|
|
|
8/20/2017 12:19:41 AM
(#1368)
Use Intellij's Delegate-refactor feature to automate moving related member methods to delegate classes, which is also automatically created by Intellij. Didn't change the implementation yet, will change it after all moving process completes.
Added Guice Tests to guarantee guice functionality.
|
8/18/2017 8:11:46 PM
into the above test failure. The cause should be We use two different dataSource to create and query test DB. In this PR, I fixed by creating a new setupDB class via leveraging new DB's API.
I mainly copied azkaban.database.AzkabanDatabaseSetup to the new class. I know this class has some coding issues, and I will refactor them in the follow-up PR
|
8/18/2017 8:00:52 PM
docs that gradle daemon should not be run in CI environments.
https://docs.gradle.org/3.3/userguide/gradle_daemon.html#when_should_i_not_use_the_gradle_daemon
|
8/18/2017 5:16:33 PM
the job to appear for 10 seconds instead of 1 second. This should help avoid test failures when they're running slower than usual for some reason.
If wait is interrupted, have another round (i--) of trying, so that the method always waits _at least_ 10 seconds before it gives up.
|
8/18/2017 5:07:23 PM
a race condition which causes Job status to be first set to some other finished status and then subsequently to KILLED. The practical implication is that when a job is killed, it's possible that it sends a JOB_FINISHED event with some other status, although it is eventually marked as KILLED.
Obviously, the final status of a job should nevertheless be "final" instead of "flapping" after a finished status has been set.
This race condition is fixed by synchronizing in both run & kill methods so that the combination of these operations are wrapped into "a single atomic operation":
checking the status and/or killed flag
based on the previous check result(s), setting the status and/or killed flag
Kill method already had the synchronization in place, but the run method was missing it.
|
8/18/2017 4:59:03 PM
(#1361)
## Issues:
The test data files are under the resource directory in the test
submodule.
Gradle tests will use the jar file that contains the data files. This
makes it harder to use these files as files directly. As a result the
build script of other submodules has to use the build directory as
dependencies instead of using the standard project dependency.
Recent changes in intellij makes the matter worse by insisting on using
its own build output directory. When compiling from intellij along
without building the test submodule first in gradle, the compilation
will fail because intellij can't find the dependent classes.
When navigating to the dependent classes defined in the test submodule,
intellij will jump to the decompiled class instead of the correct source files.
## Fix:
- Move the data files to a top level directory in the test submodule.
- Provide static methods to locate these files instead of having the
other submodules to directly hardcode the directory paths.
- Change gradle build files to use the project dependency.
- Move the java code in the test submodule to the main directory since
this code is not a test of itself but rather code to be used by other
modules.
- Add unit tests for the test module itself.
|
