1/23/2018 5:28:15 PM
PR made several changes to FlowTrigger/FlowTriggerDependency class
Made FlowTrigger and FlowTriggerDependency Serializable. This is to required by Quartz scheduler to persist scheduled job.
Added error message when doing argument validation. This is for better user experience when misconfigured flow trigger is uploaded.
Converted dependencies type from list to a hashmap with name as key for convenient lookup.
|
1/23/2018 5:26:42 PM
updates to Flow Trigger Interface set.
added runtimeProps to DependencyInstanceContext#run argument list. runtimeProps might be populated with runtime properties like starttime by azkaban if needed.
added onCancel method to DependencyInstanceCallback.
added hashmap backed implementations to key/value property holder interfaces: DependencyInstanceConfig, DependencyInstanceRuntimeProps and DependencyPluginConfig.
removed kill method DependencyCheck and added cancel method to DependencyInstanceContext to achieve the same purpose.
|
|
|
1/22/2018 4:12:42 PM
up all old stdout/stderr messages and turning them into logger messages.
In subsequent PRs, I will:
~~1) Clean up old stdout/stderr messages~~
2) Handle errors so they are also output to logger
3) Remove StdOutErrRedirect class entirely
|
|
|
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)
|
|
|
