Skip to content

fix: Remove RpcOverloadMonitor race condition - #26827

Open
abies wants to merge 1 commit into
mainfrom
26762-overload-monitor-thread-safety
Open

fix: Remove RpcOverloadMonitor race condition#26827
abies wants to merge 1 commit into
mainfrom
26762-overload-monitor-thread-safety

Conversation

@abies

@abies abies commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Description:
Given that RpcOverloadMonitor was updated from two different threads, even in the presence of volatiles, there could be a strange ordering of updates, which would lead to a delayed reaction to overload or going out of overload.

This change simplifies handling, as everything will be done from the same (dispatch) thread.

Related issue(s):

Fixes #26762

Checklist

  • Documented (Code comments, README, etc.)
  • Tested (unit, integration, etc.)

Signed-off-by: Artur Biesiadowski <artur.biesiadowski@swirldslabs.com>
@abies abies added this to the v0.79 milestone Aug 13, 2026
@abies abies self-assigned this Aug 13, 2026
@abies
abies requested a review from a team as a code owner August 13, 2026 09:51
@abies
abies requested a review from lpetrovic05 August 13, 2026 09:51
@lfdt-bot

Copy link
Copy Markdown

Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
Open Source Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@abies
abies requested review from poulok and removed request for lpetrovic05 August 13, 2026 09:51
@codecov

codecov Bot commented Aug 13, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

Impacted file tree graph

@@            Coverage Diff            @@
##               main   #26827   +/-   ##
=========================================
  Coverage     70.44%   70.44%           
+ Complexity    11662    11661    -1     
=========================================
  Files          2583     2583           
  Lines        108274   108274           
  Branches      12110    12110           
=========================================
+ Hits          76274    76278    +4     
- Misses        28017    28020    +3     
+ Partials       3983     3976    -7     
Files with missing lines Coverage Δ Complexity Δ
.../impl/network/protocol/rpc/RpcOverloadMonitor.java 97.05% <100.00%> (ø) 0.00 <0.00> (ø)
...sip/impl/network/protocol/rpc/RpcPeerProtocol.java 63.58% <100.00%> (ø) 0.00 <0.00> (ø)

... and 12 files with indirect coverage changes

Impacted file tree graph

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@testlens-app

testlens-app Bot commented Aug 13, 2026

Copy link
Copy Markdown

✅ All tests passed ✅

🏷️ Commit: 436f90a
▶️ Tests: 23483 executed
⚪️ Checks: 58/58 completed


Learn more about TestLens at testlens.app.

// we are still reporting delay to receive, not to handle
// we want to measure the network ping, rather than dispatch thread ping
// it is still handled over there, to make overloadMonitor managed from same thread
inputQueue.add(() -> overloadMonitor.reportPing(pingMillis));

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know at one point, we had performance problems that were traced back to the creation of too many lambda objects. I don't know if it is still something we need to be careful with. Is there a way to solve the problem with the lambdas?

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.

Make RpcOverloadMonitor thread safe with regards to ping vs queue size

3 participants