ICEpush
  1. ICEpush
  2. PUSH-347

Push updates being sent to multiple browser windows when they shouldn't be

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-3.3.0.GA_P02, 4.0
    • Fix Version/s: EE-4.0.0.GA, EE-3.3.0.GA_P03, 4.1
    • Component/s: Push Library
    • Labels:
      None
    • Environment:
      All

      Description

      A customer has an app that opens multiple windows. Each window makes a web service call to get data. When the data is ready it sends a push update via the Portable Renderer.

      After a few of these windows are opened and closed. The windows that remain open will all of a sudden receive push updates even though their beans are not calling the render event.

        Activity

        Hide
        Mircea Toma added a comment -

        The sequence of events that caused this issue turned out to be quite complex. When a new window is created with "Open new window" button a new window scope is created, at the same time the blocking connection is re-established in one of the windows. It turns out that the blocking request also triggers the creation of new window scopes (it should not, though). When the window is closed the remaining windows will issue a requests for updates (which is normal), because the window tracking is not enabled without a window scoped bean defined the window ID associated with the rendered view changes thus causing an update to be generated. This updates once applied triggers the reloading of text editors.

        The fix changes the WindowScopeManager to avoid creating new window scope maps for incoming resource requests. Also the manager will keep on tracking opened windows when application uses @WindowDisposed annotated view scoped beans.

        Show
        Mircea Toma added a comment - The sequence of events that caused this issue turned out to be quite complex. When a new window is created with "Open new window" button a new window scope is created, at the same time the blocking connection is re-established in one of the windows. It turns out that the blocking request also triggers the creation of new window scopes (it should not, though). When the window is closed the remaining windows will issue a requests for updates (which is normal), because the window tracking is not enabled without a window scoped bean defined the window ID associated with the rendered view changes thus causing an update to be generated. This updates once applied triggers the reloading of text editors. The fix changes the WindowScopeManager to avoid creating new window scope maps for incoming resource requests. Also the manager will keep on tracking opened windows when application uses @WindowDisposed annotated view scoped beans.
        Hide
        Jack Van Ooststroom added a comment - - edited

        This seems to break something when using @ApplicationScoped @ManagedBeans. See ICE-10472 for details.

        Show
        Jack Van Ooststroom added a comment - - edited This seems to break something when using @ApplicationScoped @ManagedBeans. See ICE-10472 for details.
        Hide
        Mircea Toma added a comment -

        Fixed ICE-10472, closing this issue as well.

        Show
        Mircea Toma added a comment - Fixed ICE-10472, closing this issue as well.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: