ICEfaces
  1. ICEfaces
  2. ICE-10462

Multiple Window Scope bean instances created on browser refresh

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: EE-3.3.0.GA_P02
          • Fix Version/s: EE-3.3.0.GA_P03
          • Component/s: Bridge, Framework
          • Labels:
            None
          • Environment:
            ICEpush, Window Scope
          • Assignee Priority:
            P1
          • Support Case References:
            Hide
            Support Case #13258 - https://icesoft.my.salesforce.com/5007000000zPvVb
            Support Case 13228 - https://icesoft.my.salesforce.com/5007000000wNn5E
            Show
            Support Case #13258 - https://icesoft.my.salesforce.com/5007000000zPvVb Support Case 13228 - https://icesoft.my.salesforce.com/5007000000wNn5E
          • Workaround Exists:
            Yes
          • Workaround Description:
            Set the windowScopeExpiration to as small as possible that the application can allow, this will allow the older bean instance to be disposed in a more timely fashion.

            Description

            A customer has found an issue where when they refresh a page it is sometimes creating new instances of their Window Scoped beans but not actively disposing the previous bean. This is causing old data to be shown when it shouldn't be.

            The issue is seen only when there is an active ICEpush connection. It also is affected by what the windowScopeExpiration is set to. If the refresh happens before this expiration setting, then the original bean instance is used and this issue is not seen.

            If the refresh happens after this expiration, a new bean instance is created. Now the page is using two unique instances of the Window scoped bean. If you wait for an addition expiration setting, the older bean is then disposed, but now a new bean instance is created.

            Having a longer expiration makes this issue worse.
            2. Zip Archive
              Case13258Example.zip
              21 kB
              Arran Mccullough

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              Arran Mccullough added a comment -

              Attached test case that shows this issue. Note: the icefaces.jar/icefaces-ace.jar files need to be added back into the war file for it to run.

              Steps:

              • Load welcomeICEfaces.jsf
              • The windowScopeExpiration is set to 20 seconds as well as there is logging to show the creation, getter, and disposal of the Window Scope bean and it's current hash code.
              • Wait 20 seconds and do a full browser refresh. A new bean instance is created.
              • Do another refresh, the getter will now register two bean has codes.
              • Waiting another 20 seconds, will have the older bean instance disposed.
              Show
              Arran Mccullough added a comment - Attached test case that shows this issue. Note: the icefaces.jar/icefaces-ace.jar files need to be added back into the war file for it to run. Steps: Load welcomeICEfaces.jsf The windowScopeExpiration is set to 20 seconds as well as there is logging to show the creation, getter, and disposal of the Window Scope bean and it's current hash code. Wait 20 seconds and do a full browser refresh. A new bean instance is created. Do another refresh, the getter will now register two bean has codes. Waiting another 20 seconds, will have the older bean instance disposed.
              Hide
              Permalink
              Judy Guglielmin added a comment -

              adding example for support case 13228.....use <serveraddress:ip>/windowsScope/13228a.jsf after building this test app (with maven or in eclipse).
              Note that the windowsScoped bean gets destroyed and reconstructed (logging in the beans to show this on server log), losing the page parameters (tabsetIndex) very frequently on weblogic ...can see instance with my name on ec2....not quite so often on tomcat7. When I add
              <context-param>
              <param-name>org.icefaces.windowScopeExpiration</param-name>
              <param-value>10000</param-value>
              </context-param>
              Also, without the push jar, the tabSetIndex (page Parameter) is never lost.
              then it is very hard to make it happen that the tabset index is lost.

              Show
              Judy Guglielmin added a comment - adding example for support case 13228.....use <serveraddress:ip>/windowsScope/13228a.jsf after building this test app (with maven or in eclipse). Note that the windowsScoped bean gets destroyed and reconstructed (logging in the beans to show this on server log), losing the page parameters (tabsetIndex) very frequently on weblogic ...can see instance with my name on ec2....not quite so often on tomcat7. When I add <context-param> <param-name>org.icefaces.windowScopeExpiration</param-name> <param-value>10000</param-value> </context-param> Also, without the push jar, the tabSetIndex (page Parameter) is never lost. then it is very hard to make it happen that the tabset index is lost.
              Hide
              Permalink
              Mircea Toma added a comment - - edited

              I cannot reproduce this issue. Once icefaces.jar is added to the deployed test case then the window scoped beans are behaving as expected. I tested with icefaces.jar built off 3.3.0-GA-maintenance and 3.3.0.GA_P02, both worked just fine.

              I'm pretty sure the test didn't work because of the missing icefaces.jar file, the window scope feature will not work without it.
              Also, the windowScopeExpiration parameter should have a value of 500 to 3000 milliseconds, depending on how long it takes to the most complex page in the application to reload (if the elapsed time between a page unload and the next page load is higher than the windowScopeExpiration value then the scope is disposed and new window scope is created if needed).

              Show
              Mircea Toma added a comment - - edited I cannot reproduce this issue. Once icefaces.jar is added to the deployed test case then the window scoped beans are behaving as expected. I tested with icefaces.jar built off 3.3.0-GA-maintenance and 3.3.0.GA_P02, both worked just fine. I'm pretty sure the test didn't work because of the missing icefaces.jar file, the window scope feature will not work without it. Also, the windowScopeExpiration parameter should have a value of 500 to 3000 milliseconds, depending on how long it takes to the most complex page in the application to reload (if the elapsed time between a page unload and the next page load is higher than the windowScopeExpiration value then the scope is disposed and new window scope is created if needed).
              Hide
              Permalink
              Mircea Toma added a comment -

              It turns out that the fixes for PUSH-347 fixed this issue as well. As already described in PUSH-347 the resource requests used to trigger new window scope creation because they do not contain ice.window parameter.

              The relevant commits are #43978 and #44012.

              Show
              Mircea Toma added a comment - It turns out that the fixes for PUSH-347 fixed this issue as well. As already described in PUSH-347 the resource requests used to trigger new window scope creation because they do not contain ice.window parameter. The relevant commits are #43978 and #44012.
              Hide
              Permalink
              Mircea Toma added a comment -

              Q: "FF and Chrome - everytime the page was refreshed the getInputOne() method was logged twice."
              A: The second getInputOne() method invocation is triggered by a request for updates that is always issued when the blocking connection is established to make sure any update that might have been generated in between connection re-establishment wasn't missed. So yes, it's normal.

              Q: "IE 11 - the page appears to refresh constantly so the getInputOne() method is logged approximately every second."
              A: I tried my local version of IE11 and also the instance on 10.18.39.107 but I could not reproduce the problem.

              Show
              Mircea Toma added a comment - Q: "FF and Chrome - everytime the page was refreshed the getInputOne() method was logged twice." A: The second getInputOne() method invocation is triggered by a request for updates that is always issued when the blocking connection is established to make sure any update that might have been generated in between connection re-establishment wasn't missed. So yes, it's normal. Q: "IE 11 - the page appears to refresh constantly so the getInputOne() method is logged approximately every second." A: I tried my local version of IE11 and also the instance on 10.18.39.107 but I could not reproduce the problem.
              Hide
              Permalink
              Liana Munroe added a comment -

              Verified Case13258Example, ICEfaces 4 trunk, ee-3.3.0 maintenance branch r44012. Verified windowsScopes test case ee-3.3.0 maintenance branch r44012. Could not re-create the IE 11 logging issue on my local machine or on 10.18.39.107 IE 11 test machine.

              Show
              Liana Munroe added a comment - Verified Case13258Example, ICEfaces 4 trunk, ee-3.3.0 maintenance branch r44012. Verified windowsScopes test case ee-3.3.0 maintenance branch r44012. Could not re-create the IE 11 logging issue on my local machine or on 10.18.39.107 IE 11 test machine.

                People

                • Assignee:
                  Mircea Toma
                  Reporter:
                  Arran Mccullough
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  6 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: