ICEfaces
  1. ICEfaces
  2. ICE-11492

Premature windowBean destruction on navigation and page reload

    Details

    • Type: Bug Bug
    • Status: Closed
    • 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

        Ken Fyten created issue -
        Ken Fyten made changes -
        Field Original Value New Value
        Attachment Log2.txt [ 23511 ]
        Attachment Log1.txt [ 23512 ]
        Attachment icefaces.zip [ 23513 ]
        Ken Fyten made changes -
        Assignee Mircea Toma [ mircea.toma ]
        Ken Fyten made changes -
        Security Private [ 10001 ]
        Mircea Toma made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Won't Fix [ 2 ]
        Ken Fyten made changes -
        Resolution Won't Fix [ 2 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Ken Fyten made changes -
        Fix Version/s EE-4.3.0.GA_P02 [ 13292 ]
        Ken Fyten made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Mircea Toma made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Mircea Toma made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Duplicate [ 3 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved: