|
|
10/25/2018 11:40:03 PM
3.60.0
in shutting down mode when its shutdown API is called. Executor will wait for all the ongoing flows to complete then shut itself down. Web server talks to executor periodically to fetch the status of each flow in its running flow cache. This PR accommodates a grace period between completion of all flows and killing the executor process, in order to allow web server to finalize flow status updating.
|
|
|
|
|
10/24/2018 12:40:07 PM
server first starts executor server, then web server.
If web server startup failed, the single server process was left running, making it harder to realize that there was an issue in startup.
This PR makes it easier to spot a startup error by stopping JVM in case of a startup error.
Without this change, the ERROR from web startup is buried in an earlier phase of the logs. The JVM keeps running despite an exception thrown by web start call because executor server's thread remains alive. As the executor server has already successfully started, it will keep logging some periodical stuff into the log file, making it harder to find out what was the last thing that happened on the web server's side.
|
|
|
|
|
10/19/2018 8:03:49 PM
(#1976)
|
10/18/2018 8:13:39 PM
by one class that's singleton itself, so no harm done for now. But this is how it should be, in case it will be injected to more than one instances later.
|
10/18/2018 7:40:06 PM
mode
This to simplify the code.
This requires users to migrate to azkaban.use.multiple.executors=true if not already using it.
After this change Azkaban will refuse to start if the property is missing or if it's set to false.
* Fix wrong comment placement & other minor fixes
* Added TODO to eventually delete checkMultiExecutorMode
* Clean up usage of executor port constants
|
