In my case the problem exists also with icefaces 1.7.2SP1.
The loading problem exists only with FF 3.0.7 when I access the application with a domain name (www.foaf-o-matic.org), but if I load the application directly from the application invoking the exact path (http://okkam.dit.unitn.it:8081/foaf-O-matic-2/) everything works fine.

With IE7 if I open first the application in a tab with this address http://okkam.dit.unitn.it:8081/foaf-O-matic-2/ , then I can access it also through www.foaf-o-matic.org. If I access only with www.foaf-o-matic.org nothing works.

Hope this can help in finding the problem.

I discovered that the issue is caused by a limitation of the
cookie based session tracking. When multiple tabs/windows are opened
simultaneously each of them will receive a new JSESSIONID cookie because
none of the GET requests received yet their corresponding response
before the other ones go out, so no cookie is set in the browser that
the subsequent requests could use. The last request that receives its
response will overwrite the JSESSIONID cookie, thus only the last
tab/window will have the right correspondence between JSESSIONID and
ice.session. That is why only one tab/window will not receive the
<session-expired/> message.
So, this is really a limitation of the cookie based session tracking
process.

Make sure that bridge is shutdown even if exceptions occur during the shutdown process.

Forum reports indicate the false "Session Expired" error is still happening on redirect navigation in some cases.

User comment from Isuru Perera on forum thread:

I tested with revision 18684 and I still have the issue.

Revision 18684 contains the changes for ICE-4275

I'm not sure why this happens and I cannot reproduce the issue from my test case.

I used Firefox 3.0.8 for testing.

Following coding is from com.icesoft.faces.webapp.http.core.RequestVerifier.service(Request)

Code:
if (request.containsParameter("ice.session")) {
if (Arrays.asList(request.getParameterAsStrings("ice.session")).contains(sessionID))

else

} else

The problem is that sometimes "ice.session" parameter is empty (i.e. empty string).

Therefore, following block is executed.

Code:
log.debug("Missmatched 'ice.session' value. Session has expired.");
request.respondWith(SessionExpiredResponse.Handler);

Earlier I was working with revision 18507 and there was no issue.
(I used revision 18507 as it fixed the file upload issue with Firefox 3.0.7)

I discovered that there could be a very short timeframe in between window.onbeforeunload and window.onunload when the ice.sessions cookie could be empty. In case there is only one window opened to an application, the ice.sessions cookie will contain only one session#counter tuple. This tuple is erased when the window is closed because the counter has value 1. This is the strategy used to avoid accumulating unused/expired sessions into the cookie.
The tuple is erased on window.onbeforeunload because its existence is tightly coupled to view disposal. If the blocking connection is unblocked (by a pong, or a ticking clock update) after window.onbeforeunload but before window.onunload when the bridge is completely shutdown the blocking connection will send a request with an empty ice.session parameter which is interpreted by the framework as a mismatched ice.session ID.

So, the solution I chose was to drop the connection instead of sending a session expired command back to the bridge. Conceptually the framework just intrprets the request as invalid instead of ice.session – servlet session id mismatch.

I upgrade latest Icefaces from trunk and notice that some changes between rev18808/28.04.2009 and 18861/11.05.2009 was done.

On current version I see in logs many messages like :
"2009-05-11 14:20:13 com.icesoft.faces.webapp.http.core.RequestVerifier service
INFO: Request missing 'ice.session' required parameter. Dropping connection..."

It happens on

• Tomcat server start
• until debugging Tomcat apps from Eclipse

I tested only Icefaces upgrade.