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:
      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.
      1. Case13258Example.zip
        21 kB
        Arran Mccullough

        Activity

        Arran Mccullough created issue -
        Hide
        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.
        Arran Mccullough made changes -
        Field Original Value New Value
        Attachment Case13258Example.war [ 17991 ]
        Attachment Case13258Example.zip [ 17992 ]
        Ken Fyten made changes -
        Assignee Mircea Toma [ mircea.toma ]
        Fix Version/s EE-3.3.0.GA_P03 [ 11572 ]
        Assignee Priority P2 [ 10011 ]
        Judy Guglielmin made changes -
        Hide
        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.
        Judy Guglielmin made changes -
        Attachment windowsScope.zip [ 18095 ]
        Ken Fyten made changes -
        Assignee Priority P2 [ 10011 ] P1 [ 10010 ]
        Hide
        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).
        Mircea Toma made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Invalid [ 6 ]
        Judy Guglielmin made changes -
        Resolution Invalid [ 6 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Hide
        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.
        Mircea Toma made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Hide
        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.
        Judy Guglielmin made changes -
        Attachment windowsScope.zip [ 18095 ]
        Judy Guglielmin made changes -
        Attachment windowsScope.zip [ 18192 ]
        Judy Guglielmin made changes -
        Attachment maven.zip [ 18193 ]
        Hide
        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.
        Ken Fyten made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Link This issue is duplicated by ICE-10642 [ ICE-10642 ]
        Ken Fyten made changes -
        Link This issue is duplicated by ICE-10642 [ ICE-10642 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved: