From 9800504ac5a6323ca1a9a2c27656dd14a961f81c Mon Sep 17 00:00:00 2001 From: Olivier Gaillard Date: Wed, 17 May 2023 15:38:41 +0000 Subject: [PATCH] Make rate limiting less aggressive for recurrent crashes Having long rate limit periods makes it more likely for crashes to get dropped if the crashes do not continue once the rate limit period is done. Change-Id: Ied5aff84e93f298bffd05d143af32f1ee8c041c7 Bug: 283096542 --- .../java/com/android/server/am/DropboxRateLimiter.java | 2 +- .../com/android/server/am/DropboxRateLimiterTest.java | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/services/core/java/com/android/server/am/DropboxRateLimiter.java b/services/core/java/com/android/server/am/DropboxRateLimiter.java index 727d4df96c474..b5c7215df899a 100644 --- a/services/core/java/com/android/server/am/DropboxRateLimiter.java +++ b/services/core/java/com/android/server/am/DropboxRateLimiter.java @@ -40,7 +40,7 @@ public class DropboxRateLimiter { // If a process is rate limited twice in a row we consider it crash-looping and rate limit it // more aggressively. private static final int STRICT_RATE_LIMIT_ALLOWED_ENTRIES = 1; - private static final long STRICT_RATE_LIMIT_BUFFER_DURATION = 60 * DateUtils.MINUTE_IN_MILLIS; + private static final long STRICT_RATE_LIMIT_BUFFER_DURATION = 20 * DateUtils.MINUTE_IN_MILLIS; @GuardedBy("mErrorClusterRecords") private final ArrayMap mErrorClusterRecords = new ArrayMap<>(); diff --git a/services/tests/servicestests/src/com/android/server/am/DropboxRateLimiterTest.java b/services/tests/servicestests/src/com/android/server/am/DropboxRateLimiterTest.java index 01563e27a7874..36a565e58f561 100644 --- a/services/tests/servicestests/src/com/android/server/am/DropboxRateLimiterTest.java +++ b/services/tests/servicestests/src/com/android/server/am/DropboxRateLimiterTest.java @@ -140,19 +140,19 @@ public class DropboxRateLimiterTest { // Repeated crashes after the last reset being rate limited should be restricted faster. assertTrue(mRateLimiter.shouldRateLimit("tag", "process").shouldRateLimit()); - // We now need to wait 61 minutes for the buffer should be empty again. - mClock.setOffsetMillis(83 * 60 * 1000); + // We now need to wait 21 minutes for the buffer should be empty again. + mClock.setOffsetMillis(43 * 60 * 1000); assertFalse(mRateLimiter.shouldRateLimit("tag", "process").shouldRateLimit()); - // After yet another 61 minutes, this time without triggering rate limiting, the strict + // After yet another 21 minutes, this time without triggering rate limiting, the strict // limiting should be turnd off. - mClock.setOffsetMillis(144 * 60 * 1000); + mClock.setOffsetMillis(64 * 60 * 1000); assertFalse(mRateLimiter.shouldRateLimit("tag", "process").shouldRateLimit()); assertFalse(mRateLimiter.shouldRateLimit("tag", "process").shouldRateLimit()); // As rate limiting was not triggered in the last reset, after another 11 minutes the // buffer should still act as normal. - mClock.setOffsetMillis(155 * 60 * 1000); + mClock.setOffsetMillis(75 * 60 * 1000); // The first 6 entries should not be rate limited. assertFalse(mRateLimiter.shouldRateLimit("tag", "process").shouldRateLimit()); assertFalse(mRateLimiter.shouldRateLimit("tag", "process").shouldRateLimit());