6/6/2017 9:22:12 PM
Actions (#1175)
Looks like the way the Save Actions intellij plugin was triggered in #1137 didn't catch certain files - including much of azkaban-web-server. This update brings files found in azkaban-web-server up to date.
|
6/6/2017 6:18:45 PM
from execution_flows table only. (#1165)
* Fetch active/queued flows from execution_flows table only. Plan to deprecate active_executing_flows table finally.
* Fix parameter passing and comments
|
|
|
6/6/2017 10:45:12 AM
3.27.0
[MutableConstantField] Constant field declarations should use
the immutable type (such as ImmutableList) instead of the general
collection interface type (such as List) private static final Set<String> MEM_KEYS = ImmutableSet ^ (see http://errorprone.info/bugpattern/MutableConstantField)
|
6/5/2017 9:15:47 PM
upload fails:
- Don't run the Job instance, just report failed status
- Try to update the node in DB anyway, because _maybe_ it was created regardless of the caught exception
|
6/5/2017 8:01:54 PM
`TriggerManager` as part of last [PR]。 I just realized that it was an incomplete Guice (mistake) without changes in AzkabanWebServer code. As a result, this PR made the fix and completely guicify `TriggerManager`.
Unless this PR gets merged, we will keep using outdated `JDBCTriggerLoader` code.
|
6/5/2017 7:26:30 PM
azkaban-exec-server (#1168)
Making changes similar to #1164
Based changes off of #1045
|
6/5/2017 5:23:50 PM
trace in error logging.
|
6/5/2017 3:40:41 PM
End Date feature to AZ schedules
Today, when we specify a flow schedule in Azkaban, the flow will run infinitely without termination as per the schedule. As #721 proposes, should schedule have an end date, the flow will have more flexibilities to be managed. In this PR, I implement the end date feature to allow users to specify the expiration date given a schedule. UI has not been changed yet in this patch (will not be implemented in near future), but people will be able to call API to leverage the new feature.
The API command sample:
`curl -k -d ajax=scheduleCronFlow -d projectName=wtwt -d flow=azkaban -d endSchedTime=14XXXXXXXXXX --data-urlencode cronExpression="0 * * ? * 6" -b "azkaban.browser.session.id=XXXXXXXXXXXXXX" http://localhost:8081/schedule`
I reuse BasicTimeChecker, as part of Expire Condition, in order to not break Old Azkaban flows. Also, Added one parameter `endSchedTime` to schedule API. If the users don't specify this parameter, Azkaban would use the default value for `01/01/2050`, and the schedule will be almost running infinitely. Besides, I add Unit tests as much as possible to guarantee that this change will not break out.
|