ICEfaces
  1. ICEfaces
  2. ICE-5919

Sessions terminated when connecting to another application instance

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Won't Fix
          • Affects Version/s: 1.8.2-EE-GA_P01
          • Fix Version/s: 1.8.3, 1.8.2-EE-GA_P02
          • Component/s: None
          • Labels:
            None
          • Environment:
            Linux dingbat 2.6.18-128.el5 #1 SMP Wed Jan 21 08:45:05 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
            Firefox 3.6
            IE 8
          • Workaround Exists:
            Yes
          • Workaround Description:
            Hide
            Configure separate domains. Instead of this:

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

            do this:

            webapp1.myhost.org/
            webapp2.myhost.org/
            Show
            Configure separate domains. Instead of this: myhost.org:8080/context1 myhost.org:8085/context2 do this: webapp1.myhost.org/ webapp2.myhost.org/

            Description

            Create two separate Glassfish domains, and deploy an ICEfaces application into each of them. The two domains are completely separate, with their own ports. They are standalone domains (they are not in a cluster).

            Individually, a browser on a client can use each on their own without error.

            However, we have found the following scenario.

            1) Connect to the application in domain A. Call this Browser A.
            2) On the same client machine, open another Tab/Window/Session in the browser and connect to the application in domain B. Call this Browser B.
            3) Once Browser B has connected, Browser A displays the message we display when an Ice.onSessionExpired event is received. So Browser A's session has expired.
            4) One the OK button is clicked in Browser A in the dialog with the session expiry message, Browser B's session is expired and displays the message.

            Surely the applications running on different domains on the same host machine should be available to the same client without this sort of impact?

              Activity

              Ascending order - Click to sort in descending order
              7 older comments
              Hide
              Permalink
              Ted Goddard added a comment -

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

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

              Show
              Ted Goddard added a comment - Servlet 3.0 allows the session ID cookie name to be configured: http://java.sun.com/xml/ns/javaee/web-common_3_0.xsd
              Hide
              Permalink
              Ted Goddard added a comment -

              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>

              Show
              Ted Goddard added a comment - 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>
              Hide
              Permalink
              Ted Goddard added a comment -

              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.

              Show
              Ted Goddard added a comment - 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.
              Hide
              Permalink
              Ed Hillmann added a comment - - edited

              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.

              Show
              Ed Hillmann added a comment - - edited 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.
              Hide
              Permalink
              Deryk Sinotte added a comment -

              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.

              Show
              Deryk Sinotte added a comment - 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.

                People

                • Assignee:
                  Deryk Sinotte
                  Reporter:
                  Ed Hillmann
                • Votes:
                  1 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: