2/3/2017 9:22:03 PM
3.15.0
up by next execution. (#892)
When manually start a flow, the initial job disabled/enabled state ( if a job is disabled or not ) should come from the last ( and only ) schedule of the flow if any modification to job states are made. The current behavior is that the initial state will be the state when the flow is uploaded. However when a job state is changed in a manual execution, the state is not persisted.
|
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)
|
