This is a sample application with which we can recreate this issue. I've included the WAR file, as well as the source used to construct it.

One note: if each domain uses a different context root for the deployed application, then we don't get the error. However, this is not a feasible long-term solution for us.

Please note, when I said "deploy an ICEfaces applciation into each of them", the same ICEfaces application is deployed into each Glassfish domain. I just want to be clear. It's not that each domain gets a different WAR file. The same WAR file is deployed into each domain.

Sorry if I wasn't clear.

The sessions are likely not actually expiring, rather ICEfaces is tracking the session expiry in a way that is confused by the similar URLS.

I have reproduced this using Tomcat 6: configure two copies of Tomcat, one on port 8080, the other on port 18080. Install auctionMonitor to both and observe the "session expired" reported in one browser window when connecting to both simultaneously.

Upon further investigation, it appears that the session actually is expiring. Most browsers associate the cookie only with the host and the path, not with the port. Therefore two different applications on different ports but with the same path will receive conflicting JSESSIONID cookies. This conflict is inherent to the Servlet Session strategy and is not specific to ICEfaces.

One option is to use URL rewriting rather than cookies for maintaining the session. This can be configured in the web application in a server-specific way.To force tomcat to use URL rewriting rather than the JSESSIONID cookie add a META-INF/context.xml file to the .war containing:

<?xml version="1.0" encoding="UTF-8"?>
<Context cookies="false">
</Context>

(This feature is only recently supported, see ICE-5871, so a current ICEfaces build is required.)

Alternatively, it may be possible to augment the server response with set-cookie2:

http://www.ietf.org/rfc/rfc2965.txt

Both Safari and Firefox failed to associate the JSESSIONID cookie with a specific port.

Related JIRA ICE-2565 with cookie behavior in Portals.

Configuration for GlassFish in sun-web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<sun-web-app>
<session-config>
<session-properties>
<property name="enableCookies" value="false" />
</session-properties>
</session-config>
</sun-web-app>

Servlet 3.0 allows the session ID cookie name to be configured:

http://java.sun.com/xml/ns/javaee/web-common_3_0.xsd

WEB-INF/sun-web.xml may work better:

<?xml version="1.0" encoding="UTF-8"?>
<sun-web-app>
<session-config>
<session-properties>
<property name="enableCookies" value="false"/>
<property name="enableURLRewriting" value="true"/>
</session-properties>
</session-config>
</sun-web-app>

Verified that auctionMonitor synchronous features work when cookies are disabled for two servers on different ports. Push only works in one of the applications, however.

I've confirmed this as well. I've tested out deploying the applications into each domain with different root contexts. And the cookies were unique. But only one of the applications received server push notifications.

I understand (I think I do, anyways!) that this is because of the server connection limits imposed by browsers. The only viable option while these limits exist will be to present the server hosting each domain as unique. As this is only an issue for our internal development/testing environments, we could do this using virtual servers.

Unless I've misunderstood the problem, though, it doesn't sound like this is an ICEfaces bug. So, I'll leave it up to you as to whether you want to close out this issue. I guess if you keep it open for future work, it could be changed as an enhancement.

The customer has accepted our suggestion to use the approach of creating separate (virtual) domains. Instead of this:

myhost.org:8080/context1
myhost.org:8085/context2

do this:

webapp1.myhost.org/
webapp2.myhost.org/

While there may be some things we could do from the ICEfaces side, they'd likely require a fair degree of customization. Resolving as Won't Fix as it's actually a configuration change for the developer.