ICEfaces
  1. ICEfaces
  2. ICE-11492

Premature windowBean destruction on navigation and page reload

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: EE-4.3.0.GA_P01
    • Fix Version/s: EE-4.3.0.GA_P02
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      The application is built with
      Java 8
      JSF Mojarra 2.2.14
      ICEfaces EE4.3.0.GA_P01
      Omnifaces 1.14.1 (No CDI dependecy)
      Spring Security 5.3
      and a number of pure Java libraries.
    • Support Case References:
      Hide
      ICEfaces Support Case #14598 has been created by Fredrik Reinodt.

      Please click on the link below to view this case in Salesforce:
      https://icesoft.my.salesforce.com/5000g00002GJ1we
      Show
      ICEfaces Support Case #14598 has been created by Fredrik Reinodt. Please click on the link below to view this case in Salesforce: https://icesoft.my.salesforce.com/5000g00002GJ1we

      Description

      The main problem is when navigating in the application it sometimes suffer from 'amnesia',
      i.e. default values are restored for a number of parameters/components.
      This is caused by a window scoped bean being recreated for a reason I cannot explain.

      Since we recently upgraded the application from ICEfaces EE4.2.0.GA to ICEfaces EE4.3.0.GA_P01 things have gone worse,
      and is now not acceptable any longer.

      My suspicion is that it is related to the changed implementation of page unload using sendBeacon() in the latest release of ICEfaces but I have no facts so support that.

      The easiest way to reproduce this is to do some changes in the GUI which are visually easy to recognize, and repeatedly press F5 a number of times (sometimes a single reload of the page is enough). Within a short time the changes in the page are restored to default values.

      A variant of this scenario leads to the user being logged out, as ICEfaces sometimes signals"allWindowsClosed" to a session scoped bean when navigating (or pressing F5). The "allWindowsClosed" is interpreted by our application code as "the user closed the browser and should be logged out".

      The timing of navigation events/reloading page with F5 semms to play significant role.

      I have done some debugging in the file org.icefaces.impl.application.WindowScopeManager.java using a modified version of your tutorial application "windowscope".
      I have found that most often the first time I can identify the erroneous behaviour after pressing F5, is in AllWindowsClosedNotifier.run()
      when state.windowScopedMaps.isEmpty() returns true, resulting in a call to AllWindowsClosed. I have also a few times seen the window bean being destroyed from DetermineOrDisposeScope.beforePhase().

      I notice that several AllWindowsClosedNotifier instances may be created before the timer is executing the run() method,
      but it doesn't seem to be a general problem (the windowScopeExpiration parameter is set to 2500 ms).
      An AllWindowsClosedNotifier object is created each time I navigate in the application or for each press of F5,
      which I guess is normal, but why does it sometimes find the state.windowScopedMaps empty?

      If I reduce the windowScopeExpiration parameter, e.g to 100 ms, I get windowBeanDestroyed (amnesia) more often and less AllWindowsClosed (logout), which is less
      catastrophic, but still not acceptable.

      The recreation of the windowsScoped bean does not allways occur immediately after the first time state.windowScopedMaps is found empty, but never before it happens. There
      might be a number of AllWindowsClosedNotifier objects created/run before the problem is obvious on the surface!

      In periods it is hard to recreate the problem, in other periods it occur most often when I navigate or update the page.
      I get the feeling this is a quite random behaviour, I cannot correlate it to any external events or specific states.


      Other (unrelated?) observations/strange behaviours:
      * After logging out, the user is redirected to the login page, but I notice that JSF tries to create a bean
      only used in secured views (logged in user). This fail silently as there is no user, but should not happen at all!.

      * Occationally I find in the logs:
      JSF1064: Unable to find or serve resource, fontawesome/fontawesome-webfont.woff, from library, icefaces.ace.
      Exception thrown: org.apache.catalina.connector.ClientAbortException: java.io.IOException: An established connection was aborted by the software in your host machine.

      Is it possible for you, out of this material, to give any advice or guidance on how to proceed debugging the premature destruction of windowBeans, what to look for, or what to change
      to make the source of the problem more obvious (or disappear!)?

      Please find my modified versions of WindowScopeManager.java and windowsScope tutorial source files attached, together with some annotated log files pointing out the unexpected occurrences of windowBean destruction and AllWindowsClosed!

        Activity

        Hide
        Mircea Toma added a comment - - edited

        Indeed the issues you are experiencing are caused by the fixes for ICE-11455 which changes the bridge implementation to use Navigator.sendBeacon native function when available.

        The main problem is that the browser is not sending the request, issued by the Navigator.sendBeacon function, synchronously. So there are many times when, during a page reload for example, the request issued by the Navigator.sendBeacon arrives at the server after the GET request for the page load.
        To solve this problem a new context parameter was introduced by ICE-11462 to define a delay in the creation of a new window scope and thus wait for the request issued by Navigator.sendBeacon. The default value for this delay is 100ms.
        You can try increasing org.icefaces.windowScopeCreationDelay value to 150-200ms which will certainly solve the problems you have described, but keep in mind that this increases the page load latency with the same amount.

        Show
        Mircea Toma added a comment - - edited Indeed the issues you are experiencing are caused by the fixes for ICE-11455 which changes the bridge implementation to use Navigator.sendBeacon native function when available. The main problem is that the browser is not sending the request, issued by the Navigator.sendBeacon function, synchronously. So there are many times when, during a page reload for example, the request issued by the Navigator.sendBeacon arrives at the server after the GET request for the page load. To solve this problem a new context parameter was introduced by ICE-11462 to define a delay in the creation of a new window scope and thus wait for the request issued by Navigator.sendBeacon . The default value for this delay is 100ms. You can try increasing org.icefaces.windowScopeCreationDelay value to 150-200ms which will certainly solve the problems you have described, but keep in mind that this increases the page load latency with the same amount.
        Hide
        Mircea Toma added a comment -

        This is a duplicate for ICE-11462.

        Show
        Mircea Toma added a comment - This is a duplicate for ICE-11462.

          People

          • Assignee:
            Mircea Toma
            Reporter:
            Ken Fyten
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: