1/10/2018 6:04:48 PM
3.40.0
(#1590)
A couple of production issues warned us that we should enforce the MAX number of concurrent executions given a flow executable. In case people accidentally schedule flows per minute or endlessly submit flows from the client side, this PR proposes to implement a simple quota to prevent it happening.
Unit Test is added.
|
|
|
1/2/2018 10:10:23 PM
(#1589)
Deletion of a project will automatically remove all of its associated schedules and go through even though associated trigger instances or flows are running. Current behavior of Azkaban is to disallow any project deletion while the project contains any flow currently being scheduled or running. User needs to remove associated schedules first and wait for all associated flows to finish or cancel any running flows in order to delete the project. However if schedule info is part of the project zip as part of flow 2.0 design, it’s impossible for user to unschedule without removing the project which becomes a deadlock scenario. This also reduces user manual labor when deleting projects.
Tested locally, but unit test or integration test will follow up.
|
1/2/2018 9:19:17 PM
3.39.1
investigation needed for better fix. (#1596)
|
|
|
|
|
12/19/2017 3:53:01 PM
Update NodeBeanLoaderTest.java
Fix merge conflict.
* Address comments.
* Address comments.
* Resolve merge conflicts. Refactor some code.
* Address comments.
|
12/18/2017 7:12:17 PM
hard linking (#1583)
Linux has restriction on shell argument length, it's likely the command to do hard linking project dir of a lot of subdir and files will exceed the restriction, causing flow setup failure. The fix is replacing the logic with java native file API.
|
|
|
12/12/2017 7:46:50 PM
Refactored some code. Addressed comments.
* Consolidated the code.
|
