Skip to content

perf: Schedule rate-limit notifications on shared executor (JAVA-653)#5814

Draft
runningcode wants to merge 2 commits into
mainfrom
no/perf/reuse-timer-executor
Draft

perf: Schedule rate-limit notifications on shared executor (JAVA-653)#5814
runningcode wants to merge 2 commits into
mainfrom
no/perf/reuse-timer-executor

Conversation

@runningcode

@runningcode runningcode commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

📜 Description

RateLimiter created a java.util.Timer (a dedicated thread) whose thread stayed alive for the rest of the process once the SDK got rate limited. The "rate limit lifted" observer notification now runs on the shared timer executor (SentryOptions#getTimerExecutorService), already used for transaction timeouts, whose single worker thread is reused and self-terminates when idle.

  • The notification is scheduled with the delay until the limit expires; to avoid an extra getCurrentTimeMillis() call the already-computed retryAfterMillis is passed through as the delay.
  • Pending notification futures are tracked (completed ones pruned on each schedule) and cancelled on close(), preserving the old Timer#cancel() semantics.

💡 Motivation and Context

Part of reducing the number of threads created by the SDK: JAVA-653.

Once an app got rate limited, this timer thread lived forever. The shared timer executor's worker is reused and idles out.

💚 How did you test it?

Existing RateLimiterTest, adapted from the Timer-mock verification to the executor/future model, plus AsyncHttpTransportTest.

📝 Checklist

  • I added GH Issue ID & Linear ID
  • I added tests to verify the changes.
  • No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
  • I updated the docs if needed.
  • I updated the wizard if needed.
  • Review from the native team if needed.
  • No breaking change or entry added to the changelog.
  • No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

Related PRs in this effort: LifecycleWatcher (#5819), performance collector (#5816), HostnameCache (#5817), batch processors (#5818).

🤖 Generated with Claude Code

@linear-code

linear-code Bot commented Jul 22, 2026

Copy link
Copy Markdown

JAVA-653

@github-actions

Copy link
Copy Markdown
Contributor

🚨 Detected changes in high risk code 🚨

High-risk code has higher potential to break the SDK and may be hard to test. To prevent severe bugs, apply the rollout process for releasing such changes and be extra careful when changing and reviewing these files:

  • sentry/src/main/java/io/sentry/transport/RateLimiter.java

1 similar comment
@github-actions

Copy link
Copy Markdown
Contributor

🚨 Detected changes in high risk code 🚨

High-risk code has higher potential to break the SDK and may be hard to test. To prevent severe bugs, apply the rollout process for releasing such changes and be extra careful when changing and reviewing these files:

  • sentry/src/main/java/io/sentry/transport/RateLimiter.java

@sentry

sentry Bot commented Jul 22, 2026

Copy link
Copy Markdown

📲 Install Builds

Android

🔗 App Name App ID Version Configuration
SDK Size io.sentry.tests.size 8.50.0 (1) release

⚙️ sentry-android Build Distribution Settings

@github-actions

github-actions Bot commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Performance metrics 🚀

  Plain With Sentry Diff
Startup time 324.94 ms 379.86 ms 54.92 ms
Size 0 B 0 B 0 B

Baseline results on branch: main

Startup times

Revision Plain With Sentry Diff
eb95ded 317.51 ms 369.08 ms 51.57 ms
2124a46 319.19 ms 415.04 ms 95.85 ms
c3ee041 310.64 ms 361.90 ms 51.26 ms
dcc6bbf 382.58 ms 462.13 ms 79.54 ms
7a19fee 315.46 ms 368.62 ms 53.16 ms
9054d65 330.94 ms 403.24 ms 72.30 ms
d500866 326.13 ms 378.70 ms 52.58 ms
ad8da22 365.86 ms 427.00 ms 61.14 ms
ed33deb 337.52 ms 484.06 ms 146.54 ms
d15471f 310.26 ms 377.04 ms 66.78 ms

App size

Revision Plain With Sentry Diff
eb95ded 0 B 0 B 0 B
2124a46 1.58 MiB 2.12 MiB 551.51 KiB
c3ee041 0 B 0 B 0 B
dcc6bbf 1.58 MiB 2.12 MiB 553.10 KiB
7a19fee 0 B 0 B 0 B
9054d65 1.58 MiB 2.29 MiB 723.38 KiB
d500866 0 B 0 B 0 B
ad8da22 1.58 MiB 2.29 MiB 719.83 KiB
ed33deb 1.58 MiB 2.13 MiB 559.52 KiB
d15471f 1.58 MiB 2.13 MiB 559.54 KiB

Previous results on branch: no/perf/reuse-timer-executor

Startup times

Revision Plain With Sentry Diff
91c5190 392.32 ms 460.78 ms 68.46 ms

App size

Revision Plain With Sentry Diff
91c5190 0 B 0 B 0 B

@github-actions

Copy link
Copy Markdown
Contributor

🚨 Detected changes in high risk code 🚨

High-risk code has higher potential to break the SDK and may be hard to test. To prevent severe bugs, apply the rollout process for releasing such changes and be extra careful when changing and reviewing these files:

  • sentry/src/main/java/io/sentry/transport/RateLimiter.java

@runningcode runningcode changed the title perf: Replace Timer threads with shared timer executor (JAVA-653) perf: Schedule rate-limit notifications on shared executor (JAVA-653) Jul 22, 2026
runningcode and others added 2 commits July 22, 2026 17:52
RateLimiter created a java.util.Timer whose thread stayed alive forever
once the SDK got rate limited. Schedule the "rate limit lifted"
observer notification on the shared timer executor instead, whose
single worker thread is reused across all timeouts and self-terminates
when idle. Pending notifications are cancelled on close().

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@runningcode
runningcode force-pushed the no/perf/reuse-timer-executor branch from 00ed5c3 to 4f33cf7 Compare July 22, 2026 15:52
@github-actions

Copy link
Copy Markdown
Contributor

🚨 Detected changes in high risk code 🚨

High-risk code has higher potential to break the SDK and may be hard to test. To prevent severe bugs, apply the rollout process for releasing such changes and be extra careful when changing and reviewing these files:

  • sentry/src/main/java/io/sentry/transport/RateLimiter.java

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant