Netflux server-side idle timeout is hardcoded at 65s and kills healthy realtime sessions in throttled background tabs (server-side counterpart of XWIKI-23928)

Summary

Netflux server-side idle timeout is hardcoded at 65s and kills healthy realtime sessions in throttled background tabs (server-side counterpart of XWIKI-23928 WebSocket disconnects in background tabs due to Chrome's "Intensive Wake Up Throttling" - XWiki.org JIRA)

Description

Environment: XWiki 18.6.0, realtime editor (netflux/chainpad), Tomcat, users on Chromium-based browsers.
 
What happens
XWIKI-23928 fixed the client-side watchdog (`MAX_LAG_BEFORE_DISCONNECT` in netflux-client.js, raised 60s → ~80s) so the browser no longer disconnects its own healthy connection under Chrome's Intensive Wake Up Throttling. However, the server-side idle timeout is still hardcoded at 65s in `Netflux.java` (xwiki-commons):

TIMEOUT_MILLISECONDS = 65000

 
A backgrounded tab is throttled by the browser to ~1 timer wake per minute, so its keepalive (20s in the foreground) stretches to ≥60s with jitter. The server closes the session as soon as the gap exceeds 65s, before the (now more tolerant) client watchdog would act. So raising the client threshold in 23928 does not prevent the disconnect; the server ends the session first.
 
Measured on 18.6.0 (production, ~500 users, netflux logger at DEBUG):

• Sessions killed at inter-message gaps of 69.6s and 71.8s, each log line stating:

  Session idle timeout is [65000]

• A synthetic idle WebSocket probe was closed by the server at exactly 65.0s.
• Baseline over 30h: 167 idle-kills, day and night, 4–14/h, abandoned background tabs cycling reconnect → throttle → kill every 2–6 minutes.
• Severity is machine-dependent (battery / energy-saver modes throttle harder), which is why some users reproduce consistently and others never do.

  Why the 5s margin is too small

  The 65s value gives only a 5s margin over the ~60s worst-case throttled wake interval, but browser timer throttling makes 60–90s gaps normal for a hidden tab, so the margin is regularly exceeded on healthy connections.

  Requested fix

  1. Make TIMEOUT_MILLISECONDS configurable (xwiki.properties), and/or raise the default to ≥130s (tolerate two missed 1-minute beats). The Yjs realtime endpoint (`xwiki-platform-yjs`) already exposes a configurable `maxIdleTimeout`; netflux should match that.
  2. Keep it consistent with the client watchdog from XWIKI-23928 (server timeout should be ≥ client threshold, not below it).

  Secondary observation: fragile channel rejoin after any disconnect

  After a disconnect (from the timeout above, or any real network blip), the client rejoins its previous realtime channel; if the server has already cleaned it up, it answers:

  ERROR ENOENT "Channel [<id>] not found"

   
  When client-side recovery does not handle this, the editor stays stuck on "Connecting" until a manual reload, and unsaved input is at risk. Observed directly in production after idle-kill events. Since connection loss is unavoidable on corporate networks, a robust rejoin (recreate the channel or resync cleanly) would materially improve reliability. Filing here alongside the timeout as they compound; happy to split into a separate issue if preferred.