The websocketInfo() lists the idleTimeout at 300 (as seen in the dump). But when I was tinkering with it, the timeout happens at 60. I am not sure if this is a browser issue or websockets ignoring the websocket.json file it itself created.
I looked into websockets disconnect time for browsers and both firefox and chrome, and what I could find, says that there is no set timeout, and usually chrome will not close a websocket for several minutes after the window goes inactive or is covered.
I’ve dug into this and the extension is actually applying idleTimeout correctly to every session — the WebSocket endpoint is per-connection (Tomcat creates a new instance for each), so every connection gets the configured 300s timeout set via setMaxIdleTimeout().
I confirmed this with a CI test that connects two clients and checks maxIdleTimeout on both sessions — both report the correct value on Tomcat 9 and 11.
Tomcat’s own default maxIdleTimeout is 0 (no timeout), so the 60s cutoff isn’t coming from there either.
The 60s is almost certainly something in front of Tomcat. Common culprits:
nginx — proxy_read_timeout defaults to 60s. For WebSocket you need:
proxy_read_timeout 300s;
proxy_send_timeout 300s;
Apache mod_proxy — ProxyTimeout defaults to 60s
HAProxy — timeout tunnel defaults to whatever timeout client is
Cloudflare / AWS ALB / etc — each has its own idle timeout
Can you check what sits between the browser and Tomcat in your setup? If you’ve got nginx or Apache as a reverse proxy, that’s almost certainly where the 60s is coming from.
That is what it would be then. I have Apache reverse proxying my websocket connection, and I did not change the settings as I just got it working. It was a frustrating weekend trying to get websockets working and just chalked up the issue to the snapshot given the other errors and issues I had (noted on the forum here).
I hate it when that happens!, anyway thanks for taking the time to flag to this problem, I have updated the docs to help others facing the same problem
"calling [onOpen] via reflection, servlet engine restart needed"
This warning appears after upgrading the WebSocket extension without restarting the servlet engine (e.g. Tomcat). The WebSocket container only allows endpoint registration once per path during its lifecycle, so when Lucee restarts but the servlet engine doesn't, the new extension forwards calls to the updated code via reflection.
This is normal — WebSocket functionality still works correctly, using reflection is just slower.
To clear the warning, restart the servlet engine, i.e. Tomcat (not just Lucee via the admin).
As of this post, reflection (not sure if this is what it is called really) does not work. If I restart my webserver, and then try to establish a websocket, it gets opened and closed immediately. I actually have to go in and restart Lucee for the websocket to work. And after I restart, everything is smooth.