8/8/2017 10:32:46 PM
(#1315)
Refactoring logic into separate smaller methods. The only logic change is a different logging statement compared to the previous one.
|
8/8/2017 7:37:00 PM
Fix for failing to kill a job due to a race condition
Problem:
After a flow starts, kill the flow quickly.
The flow and the job will show as killed. However the job actually runs
to completion.
Analysis:
Jobrunner thread runs: azkaban.jobExecutor.utils.process
.AzkabanProcess#run
A jetty thread processes the kill command:
azkaban.jobExecutor.ProcessJob#cancel
azkaban.jobExecutor.utils.process.AzkabanProcess#softKill
azkaban.jobExecutor.utils.process.AzkabanProcess#checkStarted
here it throws exception, because the job process has not been created
yet at this point.
This exception is caught and ignored.
Users are informed that the kill action is completed and reflected in
the job and flow pages.
Fix:
Synchronize the killing thread and the jobrunner thread.
The jetty thread will wait for the job process to be created if needed
before killing the job process.
If the jetty thread cancels the job before the job runner thread checks the killed flag, simply set the flag and allow the job runner thread to abort itself. ====
This is a fix built on the idea proposed in #1289
The previous fix #1253 for the same race condition is not complete.
* Fix a typo in comments
|
8/7/2017 10:09:30 PM
(#1312)
Azkaban checks if the ip associated with the session remains the same, if not, it will ask user to log in again. IP constraint offers some security benefits by preventing other people interacting with azkaban by stealing your session, but it frustrates users by forcing user to login when IP is changed.
A better alternative is to remove the IP constraint, but shorten session timeout from 24 hours to 10 hours. 10 hours is a short period not to compromise security too much. At the same time, most users only need to login once a day with it.
test methodology:
issue ajax api with same session id from two different hosts, both of them return successful results.
|
8/7/2017 6:42:45 PM
gradle wrapper to use version 4.02
See
https://docs.gradle.org/current/release-notes.html
* Update gradle wrapper jar as well
This version seems to be stable.
Ran
./gradlew wrapper
* Fix copywrite notice for the build.gradle file
|
8/7/2017 3:24:17 PM
Change API's concurrent default option to skip
Today, given a schedule, the default option for concurrent setting is ignore, that is, allowing concurrent executions whatever schedule triggers. This could be regarded as a bug in current AZ. The reason is that, In UI, the default schedule option is "skip" while API's default option is "ignore". The inconsistency between API and UI should be resolved.
This commit fixes the option to skip. When next schedule triggers, as long as the last execution hasn't finished, it won't trigger the next execution. As a consequence, this commit changes API's default option to "skip" and UI's default behavior is not affected. Tested on our staging cluster, and working.
|
8/6/2017 5:34:24 PM
clean build took 22 seconds vs > 1 minute before this change.
output:
BUILD SUCCESSFUL
Total time: 22.587 secs
120 tasks in build, out of which 81 (68%) were executed 13 (11%) up-to-date 13 (11%) no-source 13 (11%) loaded from cache 6 (5%) cache miss 75 (63%) not cacheable
|
8/3/2017 6:04:49 PM
dep: httpcore (#1306)
Updating httpclient dependency to the latest
https://mvnrepository.com/artifact/org.apache.httpcomponents/httpclient
Removing httpcore since it is a dependency of httpclient and will be pulled in automatically.
|
|
|
8/2/2017 7:54:11 PM
login warning (#1303)
This commit reverts the XMLUserManager code since it is found that we don't need to customize XML error login message, since only headless users access from XMLUserManager. Standard users go through LDAPUserManager, which we already added this feature.
The original PR is at: #1277
|
8/2/2017 7:14:11 PM
class (#1294)" (#1304)
This reverts commit 9d079ec.
This change removed an API (getSessionData) relied upon by the hdfs viewer.
|
