Introduced SessionTimeoutMonitor resource handler which monitors session timeout by keeping updated a last access timestamp in the session. The monitor excludes icepush related requests from updating the last access timestamp as opposed to the servlet container. This allows the monitor to detect when the only incoming requests are icepush initiated requests and expire the session.

So the mechanism for handling session expiry when Push requests are active is:

• A ResourceHandler called SessionTimeoutMonitor is active and reviews each incoming request.

• Each incoming request does touch the session, so the SessionTimeoutMonitor detects whether or not the requests is a Push request or not.
• If a the request is a not a Push request, then we create/update a our own synthetic timeout value in the session.
• If a request is a Push request, then we do not modify this sythetic session value.

• Finally, each request looks at the synthetic expiry value and, if the maxInactiveInterval has been exceeded, expires the session programmatically.

What this means is that, if there are ONLY Push requests coming in, the "real" container session will never expire but our synthetic session activity calculation will eventually determine that a request (either Push or non-Push) has occurred that is longer than the maxInactive interval.

Something we should note. Due to the nature of our calculation, our synthetic session expiry could occur up to one "heartbeat" later than an actual session expiry triggered by the servlet container. This is because an incoming Push request could fall just short of actually triggering the synthetic expiry and it would have to wait for the next "heartbeat" to trigger it. Currently, the default "heartbeat" interval for Push is 50 seconds which means that, given a real session timeout of 5 minutes, a synthetic expiry may occur as late as 5 minutes + 50 seconds.

If this is deemed unacceptable, we could potentially mitigate this by:

• doing a more complex calculation and calling setMaxInactiveInterval in order to try and get the servlet container to trigger the timeout at the exact time
• use Filters (Servlet/Portlet 2) to achieve better results (we declined to do this in 1.8 due to the fact that it made the configuration more complex and that there were no filters for Portlets but both of these problems have been somewhat reduced since then)
• discussing other possible solutions

This feature no longer seems to be working correctly.

Using icefaces2/trunk rev. #22683 any sample with push active will never expire.

Tested were compat showcase with lazyPush=false as well as auctionMonitor.

Compat showcase with lazyPush=true expires as expected (and displays Session Expired dialog after user interaction post-expiry).

Auction seems to expire fine though.

Defining SessionExpiredListener in the core taglib file instead of using Servlet 3.0 annotation so that apps running in Servlet 2.5 containers can still work.

When redirect URI is not defined set null object instead of 'null' as JS configuration value. This way the bridge will not try to use 'null' value as URI to redirect to.

Testing with rev # 22707 shows that compat auctionMonitor never seems to expire.

When 'strictSessionTimeout' is enabled I can see "Network Connection Interrupted" indicator showing up when the session expires. On a closer look I can see the "User Session Expired" popup rendered under the "Network Connection Iterrupted" popup. This is due to the decoupling we now have between ICEfaces bridge and ICEpush bridge, the ICEpush bridge has no knowlenge about sessions it just sees the network connection dropped.

Changed session expired indicator to disable connection lost and connection trouble indicators on session expiry.