4/4/2017 5:04:45 PM
for execution. (#959)
It consists of following changes:
1. Old code will execute two same flows if they are being submitted at the same time even though concurrent running option is disabled. We use combination of project name, flow name and a fixed suffix to synchronize on making sure submitting flow method is mutual exclusive to same flows' different submissions.
2. Add log before a scheduled flow starts.
3. Checks the running candidate as well in submitExecutableFlow. There're two threads: producer thread which puts flow to be executed into the waiting queue, and consumer thread which polls from the queue and dispatch for execution. There's a short period between consumer polls an flow(runningCandidate in the code) from the waiting queue and dispatching it, during which the flow is neither in waiting state and running state. At that time, producer checks the flow is not in waiting queue and running queue, then puts it in the waiting queue. Then two same flow are going to be dispatched together. The fix is making the runningCandidate as shared variable so that it can be checked by producer as well. This won't fix the race condition 100% since there always could be mis-synchronization in between, but it reduces the chance a lot.
|
3/30/2017 9:05:04 PM
(#958)
* Issue #957 - fixes to azkaban-solo start & shunit2 unit tests
* Added guard to ensure pid exists before kill attempt. Additionally, I
reduced the Xmx value for the azkaban solo server from 3G to 512M, and
added jdwp settings to attach a local debugger.
|
3/30/2017 12:54:38 AM
Log exceptions in ScheduleServlet
|
3/28/2017 3:45:37 PM
(#961)
Adding a log statement to capture plugin details and the classpath which is used to create the classloader for loading plugins.
|
3/27/2017 5:23:54 PM
method to FlowPreparer class - Simplified ProjectVersion class - All setup methods consolidated in FlowPreparer - Project Download and setup is also handled by FlowPreparer - Adding tests for FlowPreparer
|
|
|
3/23/2017 8:18:54 PM
shutdown API is called. (#947)
When shutdown api is called, executor will deactivate itself, wait for all the job to finish, then call system.exit(), which triggers the shutdown hook. In shutdown hook, executor clears the database entry and forces a shutdown of all active threads.
|
3/22/2017 7:42:56 PM
script was updated with the new shared logic - launch script was refactored - launch script to fail if server already started.
|
|
|
3/20/2017 6:45:27 PM
when executor host is running out of memory (#937)
Currently a job will be killed right away before actual execution if there's not enough memory. But as memory usage fluctuates, it's possible there will be enough memory later. Therefore we should retry the job if memory requirement is not met.
Testing:
Given the nature of this code change, it's difficult to add automated tests. For now we tested the change as by replacing SystemMemoryInfo.canSystemGrantMemory with a function which returns true or false based on given probability, then manually verified it's logging correctly and hitting the according code path.
|
