1/4/2017 10:36:55 PM
3.13.0
jobtypes. (#866)
|
1/4/2017 10:32:25 PM
3.10.0
* remove schedules table since it is no longer used for long time
* removing unused file
* restore the file to github repo
* adding upload time index in table execution_logs
|
1/4/2017 7:45:47 PM
incorporating many API changes that took place from Jetty 6 to Jetty 9.
Removed JmxJettyServer class which does not seem to be used anywhere.
Fixed tests
|
12/15/2016 11:22:00 PM
API for executor
Usage: hostname:port/executor?action=shutdown
Safe shutdown implies the following:
- Mark itself inactive in the DB
- Signal shutdown on the execution pool. No further jobs are accepted.
- Awaits termination of the pool.
- Shuts down the Jetty server post shutdown of execution pool
In odd cases the executor will still fail to completely kill itself. Those issues will be addressed in a upcoming different patch.
* Refactor: Organizing members in FlowRunnerManager. Marking final wherever possible.
|
12/15/2016 8:36:49 PM
(#852)
URLs, which are referenced by names known as a "topic" are specified in
azkaban.properties
For example if you want an external URL under the topic of
"arbitraryName", you would put the following line into
azkaban.properties:
azkaban.server.external.arbitraryName.url=http://someURL.com
Additionally, an external log viewer can then be specified using the
parameter azkaban.server.external.logviewer.topic=arbitraryName
This line would reference the URL specified earlier in this description
(http://someURL.com) as an external log viewer.
A similar behavior has been added for specifying external analyzers, ie.
azkaban.server.external.analyzer.topic=arbitraryName
Note that this commit is NOT backwards compatible and deprecates the
mechanism created in (#657). That commit specifies external analyzers
with the config
execution.external.link.url=http://someURL.com/?%url
This must now be specified as
azkaban.server.external.arbitraryName.url=http://someURL.com/?${url}
azkaban.server.external.analyzer.topic=arbitraryName
|
12/14/2016 6:49:50 PM
(#854)
When we use the log4j Kafka appender, it seems that the appender
simply does not log the stack trace anywhere. Seeing as the stack trace is a very important piece of information, we create our own PatternLayout class that appends the stack trace to the log message that reported it, so that all the information regarding that error can be found one in place.
|
12/12/2016 11:25:38 PM
are being filled with this message without apparent reason.
Removing this will increase readability of logs.
|
12/12/2016 6:12:12 PM
override change
|
12/9/2016 7:39:33 PM
info (#848)
|
12/5/2016 6:51:29 PM
3.12.0
under utils that will tie out and err to log4j. This
class does this in the main functions of AzkabanWebServer and
AzkabanExecServer, so that all out going messages will be caught by
log4j.
|
