1/12/2017 9:42:08 PM
Jettry upgrade, servlet-api:3.1.0 is automatically loaded. However, azkaban-common is still using servlet-api:2.5.0, which caused inconsistency when running az (getting http request) though build is fine. In this change, we remove this jar.
|
1/9/2017 9:29:20 PM
Azkaban Triggers are checked via the SlaChecker class. The logic is failing for certain conditions where user flows would keep running despite SLA expiry. Though the logic seems to be working for most cases, it seems to be quite complicated + confusing with lot of code duplication.
Changes: The SlaChecker class has been rewritten with unit tests to cover all the relevant code paths. This ensures that the Checker works correctly.
+ updated gradle version
|
1/9/2017 6:18:12 PM
# syntax (#870)
|
1/7/2017 6:43:32 PM
this fixes:
- Wasn't enabling jobs inside sub-flows in case of certain flow statuses
- Wasn't enabling jobs if they were left in running or queued state
So the following changes:
- Always handle statuses of jobs inside all sub-flows
- Also enable for rerun if job was left in running or queued state
- Disable if job wasn't present in the flow during the original execution (see node.noInitialStatus in the code)
- Simplify code
I don't know why sometimes jobs get left in running / queued state even after the execution has been killed. That's some other bug. This fix makes the UI behave nicely also with that kind of executions.
This fix was validated against some existing killed & failed executions. Some jobs/sub-flows that were not present in the flow during the original execution were enabled - after this fix they are not. Some jobs/subflows that were left in running or queued (although the flow itself has killed status) were disabled - with these fixes they are enabled as desired.
|
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.
|
