2/3/2017 9:08:56 PM
azkaban/azkaban#869
The current code seems to trigger incorrect SLA alerts and spam users. Azkaban seems to report an alert where every 2 min where the job SLA is 60 min. Revert the change till we can investigate the root cause.
|
2/3/2017 8:52:19 PM
syncing ensures that the messages are in order. However, the problem is that the syncing also slows down the transaction rate of these messages drastically. This affects the service significantly and is a blocking call. Reverting this change which was added to #852
|
2/1/2017 11:22:35 PM
log.error statements in a bunch of places in StatsServlet
|
2/1/2017 10:56:15 PM
project files. (#891)
The initial value of active flag in FlowRunnerManager was set to true by mistake previously.
|
1/22/2017 1:46:32 AM
Fix #394
|
|
|
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.
|
