reactor/reactor-core

Improve Flux.timeout efficiency

Open

#2845 aperta il 21 nov 2021

Vedi su GitHub
 (17 commenti) (3 reazioni) (0 assegnatari)Java (1164 fork)batch import
area/performancefor/user-attentionhelp wanted

Metriche repository

Star
 (4748 star)
Metriche merge PR
 (Merge medio 16g 15h) (25 PR mergiate in 30 g)

Descrizione

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

Guida contributor