Unfortunately, real world testing showed the adaptive timeout to be far to adaptive. It was not unusual to see fairly long strings of low latency values (which the algorithm quickly converged on) followed by a substantially higher latency. The algorithm has been modified as follows to never adjust up or down by too much, and to always give much more weight to the current value:

responseDelay = Math.max(responseDelay,
(connectionRecreationTimeout * 4) / 5);
responseDelay = Math.min(responseDelay,
(connectionRecreationTimeout * 3) / 2);
responseDelay = Math.max(responseDelay, 500);

connectionRecreationTimeout =
(responseDelay + (connectionRecreationTimeout * 4)) / 5;

The adaptive heartbeat is working as expected. The only influence that the adaptive heartbeat has on the reconnect timeout adjusting is that the calculations are made at increasingly wider intervals, in the case of a idle application.

Introduced mechanism for automatically adjusting the connection recreation timeout. The adjusting algorithm is based on the current response-request delay.
Also when duplicate blocking requests are detected the timeout value is reverted to the previous one since these duplicate requests can extend excessively the calculated delay. The duplicate requests occur during page reload or navigating away from the page and then returning back before the server decides to sever the connection.

It should be possible for the recent logging code added to ThreadBlockingAdaptingServlet to share code with this feature.

Adaptive heartbeat should be verified at the same time as this feature.

Algorithm to maintain the running average reconnect time T.
If the most recent reconnect request T1 is within 2 x T, set T1 = max(T1, 0.5s) T = (T1 + T)/2
If the reconnect request does not arrive within 2 x T, leave T unchanged and switch to cloud push.