|
|
|
|
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
|
10/18/2018 5:15:15 PM
(#1975)
* Create a unit test for RunningExecutionsUpdater
* Move update request code to ExecutorApiGateway
Better scope for RunningExecutionsUpdater & cleaner unit tests
* Added test updateExecutionsSucceeded() & used constant for "error"
|
|
|
