Skip to content

feat: limit and measure the client API's handler threads - #441

Merged
devopvoid merged 2 commits into
mainfrom
feat/client-load-limits
Oct 25, 2026
Merged

devopvoid merged 2 commits into
mainfrom
feat/client-load-limits

Conversation

@devopvoid

Copy link
Copy Markdown
Owner

Slow handlers of many peers or subscriptions could take a thread each, and onAudio always buffered up to five seconds.

  • WebRtc.Builder.eventThreads(n) and frameThreads(n) cap the pools handlers run on (unlimited by default). The control pool stays unlimited, since its tasks wait for each other.
  • Peers and subscriptions take turns of at most 64 tasks or 10 ms; frame and audio dispatchers hand over one item per task. A limited pool rejects nothing while it runs, so no future stays open.
  • WebRtc.loadStats() reports queued, oldest waiting, active and dropped work for control, events, video and audio, plus the pools' thread counts.
  • The audio buffer is set by Builder.audioBuffer(Duration) or per subscription with onAudio(Duration, handler).

Event and frame pools can be capped with eventThreads and frameThreads;
peers and subscriptions take turns of at most 64 tasks or 10 ms, and a
limited pool rejects nothing while it runs. WebRtc.loadStats() reports
queued, oldest waiting, active and dropped work. The audio buffer of
onAudio is set by audioBuffer or per subscription.
# Conflicts:
#	webrtc/src/main/java/dev/onvoid/webrtc/client/WebRtc.java
@devopvoid
devopvoid merged commit eca1493 into main Oct 25, 2026
25 checks passed
@devopvoid
devopvoid deleted the feat/client-load-limits branch October 25, 2026 12:47
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