It turns out the can of worms was rather larger than it first appeared.
The bulk of the issues should now be resolved. I just have a few things
I wanted to check that I spotted during the back-ports.
Mark
On 03/09/2026 10:03, Rémy Maucherat wrote:
On Thu, Sep 3, 2026 at 10:44 AM Mark Thomas <[email protected]> wrote:
- Iterate through the entire list of endpoints in the background thread.
The async timeouts (which have no IO) do that, the background thread
calls timeoutAsync on all processors to see if something should
happen. So it couldn't be more basic, but nobody complained.
The first option, as you point out, gets complicated, fast. The second
option would ensure that entries are timed out in the correct order. The
third option is the simplest.
I am trying to determine how important it is that endpoints are timed
out in the correct order. In the static resource cache, that has similar
code, it was more obvious that correct order had a benefit. The benefit
is not as clear for WebSocket writes but I think it is worth doing as it
simplifies reasoning about timeout behaviour.
+1
It would use "public void register(WsRemoteEndpointImplServer
endpoint, long timeoutExpiry)" instead, and I have a patch ready.
Hang on to that patch. I may still end up tying myself in knots.
It's the "timeout.patch" file I attached to a previous reply in the
thread, so it won't get lost since it's in the archive. There's a test
case too for the structure (written from before the inclusion of the
change to avoid re registering without removing when useAsyncIO=false,
so it focused on that).
Rémy
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
