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.
|
6/5/2017 3:32:52 PM
Fixing DefaultCharset warnings in azkaban-common
* Used #1045 to base changes off of
|
|
|
|
|
6/4/2017 6:03:28 PM
previous test jobs so that .succeedJob() is called on the retried job instance.
So now we can remove all @Ignores.
How does this help?
When a job run is started, the created job type instance gets added into InteractiveTestJob's map. If a job is retried, another instance is created, but for InteractiveTestJob the key=jobname is the same.
My commit message says:
Clear previous test jobs so that .succeedJob() is called on the retried job instance.
So occasionally it happened that InteractiveTestJob.getTestJob("jobb:innerJobB").succeedJob was targeted at the original failed instance. After that the retry attempt instance was added into InteractiveTestJob's map, but succeedJob was never called on it, so it was left in RUNNING state.
|
6/4/2017 5:16:59 PM
remove duplicate code
|
