reactor/reactor-core

Improve Flux.timeout efficiency

Open

#2,845 opened on Nov 21, 2021

View on GitHub
 (17 comments) (3 reactions) (0 assignees)Java (1,164 forks)batch import
area/performancefor/user-attentionhelp wanted

Repository metrics

Stars
 (4,748 stars)
PR merge metrics
 (Avg merge 16d 15h) (25 merged PRs in 30d)

Description

Current implementation uses parallel scheduler by default which is in essence a ScheduledThreadPoolExecutor which has the task queue guarded by ReentrantLock, which means two trips through said lock per signal on average

After looking at Netty's https://github.com/netty/netty/blob/4.1/handler/src/main/java/io/netty/handler/timeout/IdleStateHandler.java there appears to be a way to do fewer timeout task reschedules if you let go of the idea illustrated by the current marble diagrams (new signal cancels the previous timeout task)

WDYT? this really prevents Flux.timeout from being useful with high-frequency publishers which may occasionally stall

suggestion inspired by https://gitter.im/reactor/reactor?at=61968a44197fa95a1c7adf05

Contributor guide

Research direction
Examine the current Flux.timeout implementation, particularly the default parallel scheduler and its ReentrantLock usage. Study Netty's IdleStateHandler to understand its timeout management. Propose an alternative rescheduling approach that reduces lock contention for high frequency publishers.
Tech stack
java
Domain
backend
Issue type
Performance
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
JavaReactor
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
35