ICEpush
  1. ICEpush
  2. PUSH-180

ICEpush updates fail to resume after session expiry and reload

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: EE-3.2.0.BETA, EE-3.2.0.GA, 3.3
    • Component/s: Push Library
    • Labels:
      None
    • Environment:
      ICEpush svn rvn#29938, icefaces3/trunk rvn#29975
    • Assignee Priority:
      P1
    • Workaround Exists:
      Yes
    • Workaround Description:
      Instead of reloading the application in the same browser tab, open it in a new tab.

      Description

      When running compat/auctionMonitor and letting the user-session expire, after clicking "reload" on the expiry error dialog, the application reload and can be interacted with, but the push events do not resume.

      If you close the tab and open a new tab in the same browser, the push events are active once again.

        Activity

        Ken Fyten created issue -
        Ken Fyten made changes -
        Field Original Value New Value
        Workaround Description Instead of reloading the application in the same browser tab, open it in a new tab.
        Workaround Exists [Yes]
        Salesforce Case []
        Assignee Priority P1
        Assignee Mircea Toma [ mircea.toma ]
        Hide
        Mircea Toma added a comment -

        I cannot reproduce this issue. First of all, compat/auctionMonitor will not expire by itself unless its web.xml file is changed to include org.icefaces.strictSessionTimeout=true context parameter.

        Once I added the context parameter the application expired as expected, showing the "User Session Expired" popup but when the page was reloaded ICEpush notifications resumed.

        Show
        Mircea Toma added a comment - I cannot reproduce this issue. First of all, compat/auctionMonitor will not expire by itself unless its web.xml file is changed to include org.icefaces.strictSessionTimeout=true context parameter. Once I added the context parameter the application expired as expected, showing the "User Session Expired" popup but when the page was reloaded ICEpush notifications resumed.
        Mircea Toma made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Cannot Reproduce [ 5 ]
        Hide
        Ken Fyten added a comment -

        To reproduce this issue I use the following steps:

        1. Run the auction-monitor demo on another machine
        2. Load auction-monitor into your browser (on a machine other than the tomcat one)
        3. See the clocks tick.
        4. Put the browser machine to sleep
        5. Wait longer than the session expiry internal on the app.
        6. Wake the browser machine
        7. See no clocks ticking.
        8. Interact with the application.
        9. See the "Session Expired" dialog.
        10. Click "reload" on the dialog.
        11. App reloads, see no clocks ticking.
        12. Interact with the app., see the app. functioning.
        13. See no clocks ticking.
        14. Open another tab for the app., see clocks ticking in new tab now.

        Show
        Ken Fyten added a comment - To reproduce this issue I use the following steps: 1. Run the auction-monitor demo on another machine 2. Load auction-monitor into your browser (on a machine other than the tomcat one) 3. See the clocks tick. 4. Put the browser machine to sleep 5. Wait longer than the session expiry internal on the app. 6. Wake the browser machine 7. See no clocks ticking. 8. Interact with the application. 9. See the "Session Expired" dialog. 10. Click "reload" on the dialog. 11. App reloads, see no clocks ticking. 12. Interact with the app., see the app. functioning. 13. See no clocks ticking. 14. Open another tab for the app., see clocks ticking in new tab now.
        Ken Fyten made changes -
        Resolution Cannot Reproduce [ 5 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Ken Fyten made changes -
        Salesforce Case []
        Ken Fyten made changes -
        Salesforce Case []
        Fix Version/s 3.2 [ 10340 ]
        Fix Version/s 3.1 [ 10310 ]
        Hide
        Mircea Toma added a comment - - edited

        I managed to reproduce the issue when following the steps provided above. The problem doesn't show up consistently though, approximately only 1 out of 5 retries will manage to exhibit the problem.
        It seems that the problem is not on the client side nor ICEpush, not even ICEfaces but in JSF or the servlet container. In the occurrences when the blocking connection is not restarted the inline JS code the registers the pushIDs with the ICEpush bridge is not present (ice.setupPush(....) call). This code is rendered by BridgeSetup which decide to render the initialization code based on the value returned by LazyPushPanger.enablePush method. The method will return true when lazy push is disabled or when the rendered view requires ICEpush support, this is done usually by calling PushRenderer.addCurrentSession or PushRenderer.addCurrentView methods.
        In auctionMonitor PushRenderer.addCurrentSession is called indirectly (through the old SessionRenderer) from the UserBean constructor, a session scoped bean. The problem occurs here, when a new session is created a new bean is instantiated and PushRenderer.addCurrentSession is called. When the blocking connection does not start there is no UserBean instantiated thus PushRenderer.addCurrentSession is not called.
        Even if a new @PostConstruct annotated method is introduced to invoke PushRenderer.addCurrentSession on session activation does not seem to help. Making the bean Externalizable to verify if the bean is created by deserialization shows that that is not the case.

        Show
        Mircea Toma added a comment - - edited I managed to reproduce the issue when following the steps provided above. The problem doesn't show up consistently though, approximately only 1 out of 5 retries will manage to exhibit the problem. It seems that the problem is not on the client side nor ICEpush, not even ICEfaces but in JSF or the servlet container. In the occurrences when the blocking connection is not restarted the inline JS code the registers the pushIDs with the ICEpush bridge is not present (ice.setupPush(....) call). This code is rendered by BridgeSetup which decide to render the initialization code based on the value returned by LazyPushPanger.enablePush method. The method will return true when lazy push is disabled or when the rendered view requires ICEpush support, this is done usually by calling PushRenderer.addCurrentSession or PushRenderer.addCurrentView methods. In auctionMonitor PushRenderer.addCurrentSession is called indirectly (through the old SessionRenderer) from the UserBean constructor, a session scoped bean. The problem occurs here, when a new session is created a new bean is instantiated and PushRenderer.addCurrentSession is called. When the blocking connection does not start there is no UserBean instantiated thus PushRenderer.addCurrentSession is not called. Even if a new @PostConstruct annotated method is introduced to invoke PushRenderer.addCurrentSession on session activation does not seem to help. Making the bean Externalizable to verify if the bean is created by deserialization shows that that is not the case.
        Migration made changes -
        Fix Version/s EE-3.2.0.GA [ 10323 ]
        Fix Version/s 3.2 [ 10340 ]
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #32791 Wed Dec 12 17:28:53 MST 2012 mircea.toma PUSH-180 Try to discard the window scope when dispose window request is received after a browser window unload. This ensures that no scope map that should have been expired is still used.
        Files Changed
        Commit graph MODIFY /icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/application/WindowScopeManager.java
        Hide
        Mircea Toma added a comment -

        Modified WindowScopeManager to try to discard the window scope when dispose window request is received after a browser window unload, ensuring that no scope map that should have been expired is still used.
        This issue occurred because after the browser machine is put to sleep no other requests are coming in, to allow the server side code to check if the window scopes belonging to a certain session should be discarded or not.

        Show
        Mircea Toma added a comment - Modified WindowScopeManager to try to discard the window scope when dispose window request is received after a browser window unload, ensuring that no scope map that should have been expired is still used. This issue occurred because after the browser machine is put to sleep no other requests are coming in, to allow the server side code to check if the window scopes belonging to a certain session should be discarded or not.
        Mircea Toma made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Fix Version/s 3.3 [ 10374 ]
        Ken Fyten made changes -
        Fix Version/s EE-3.2.0.BETA [ 10574 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved: