Prior to ICEfaces 1.8, the list of ice.session values was stored in a JavaScript global window variable. New ice.session values would be added when a new view was loaded and automatically cleaned up when the window closed. These values are now stored in a cookie. This allows the values to be shared across all the windows/tabs for a given domain, but it also requires that we manually manage the loading and removal of values - when all the views for a particular ice.session are gone, the ice.session value is removed.

The problem in ICEfaces 1.8.0 is that the code to remove the ice.session values from the cookie executes before the page is fully unloaded. This results in a potential timing issue where a reload (e.g. caused by an attempt to failover to a different node in a cluster) causes the ice.session value to be removed but the blocking connection (used for Ajax Push) still attempts to re-establish itself without a valid ice.session being available. Continued and repeated attempts are made by the blocking connection until the page reload occurs and before the ICEfaces bridge is completely shut down, resulting in the noted error messages.

The effect in the browser can be fairly innocuous depending on the number of attempts made to re-establish the blocking connection and the time it takes for the page reload to shut down the bridge and reload the page. However, if many attempts are made, then the browser may appear unresponsive for an indeterminant amount of time.

The problem has been solved in the upcoming ICEfaces 1.8.1 by shutting down the bridge earlier, so that the blocking connection never attempts to re-establish contact without a valid ice.session value in the cookie.

Shutdown bridge as soon as 'reload' command is received to avoid having a blocking connection running with no participating session ID.

Need to verify this change using all use-cases that can result in the bridge triggering a "reload", such as reload navigation.

Assigning to Mircea...

Changed Fix Version(s) to 1.8.1