Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-Alpha2
    • Fix Version/s: 2.0-Beta1, 2.0.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces, session replication

      Description

      Many of the Objects maintained by ICEfaces in the Session are likely unnecessary and can be instantiated as needed in the request cycle. This should be optimized to reduce unnecessary object replication in cluster environments.

        Issue Links

          Activity

          Hide
          Mircea Toma added a comment -

          Ted said:

          "Session Attribute: org.icefaces.application.LazyPushManager

          Maintains list of view keys (not viewID) for views making use of push.

          When failover occurs, push group membership should automatically fail over.

          If possible, ICEfaces should avoid duplicating JSF data structures (the table of view keys is a partial duplication of JSF state management)."

          It is a duplication of IDs, that's all. The reason is reasonably well explained in http://jira.icefaces.org/browse/ICE-5594?focusedCommentId=28866&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_28866 comment.

          "PushRenderer.addCurrentSession()

          • set a Session attribute containing the PUSHID for the session. If this session attribute is detected during page rendering, add the ICEpush JavaScript to the page."

          This strategy doesn't hold if PushRenderer.addCurrentSession is invoked a number of times and different from how many times PushRenderer.removeCurrentSession is called. That's the reason for the "noOfRegistrations" counter in LazyPushManager. Yes, the counter can be kept directly into the session, but implementation wise you end up with lots of session attributes that the different "managers" will use – global variable syndrome once again....which I hate.

          "PushRenderer.addCurrentView()

          • set a viewMap attribute containing the PUSHID for the view. If this view attribute is detected during page rendering, add the ICEpush JavaScript to the page."

          The viewMap is not the right container since the viewIDs are actually 1-to-1 mapped to the view state keys. The view state keys represent the state of the different views currently active for a session.

          In the end LazyPushManager could be merged with SessionViewManager, but really its functionality is orthogonal to the one of SessionViewManager.

          Show
          Mircea Toma added a comment - Ted said: "Session Attribute: org.icefaces.application.LazyPushManager Maintains list of view keys (not viewID) for views making use of push. When failover occurs, push group membership should automatically fail over. If possible, ICEfaces should avoid duplicating JSF data structures (the table of view keys is a partial duplication of JSF state management)." It is a duplication of IDs, that's all. The reason is reasonably well explained in http://jira.icefaces.org/browse/ICE-5594?focusedCommentId=28866&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_28866 comment. "PushRenderer.addCurrentSession() set a Session attribute containing the PUSHID for the session. If this session attribute is detected during page rendering, add the ICEpush JavaScript to the page." This strategy doesn't hold if PushRenderer.addCurrentSession is invoked a number of times and different from how many times PushRenderer.removeCurrentSession is called. That's the reason for the "noOfRegistrations" counter in LazyPushManager. Yes, the counter can be kept directly into the session, but implementation wise you end up with lots of session attributes that the different "managers" will use – global variable syndrome once again....which I hate. "PushRenderer.addCurrentView() set a viewMap attribute containing the PUSHID for the view. If this view attribute is detected during page rendering, add the ICEpush JavaScript to the page." The viewMap is not the right container since the viewIDs are actually 1-to-1 mapped to the view state keys. The view state keys represent the state of the different views currently active for a session. In the end LazyPushManager could be merged with SessionViewManager, but really its functionality is orthogonal to the one of SessionViewManager.
          Hide
          Mircea Toma added a comment - - edited

          All these objects need access to objects that can be constructed only locally, such as PushContext or ServletContext. The managers should be changed so that they won't keep references to instances of ServletContext and such, but they would receive them when their methods are invoked.
          For example SessionViewManager.addView(String id) would be change to SessionViewManager.addView(String id, PushContext context) since the method uses internally PushContext class.
          Also the fields of the managers can be saved into a serializable structure (without behavior) and that will be saved into the session (thus session scoped).
          This approach will allow the creation of the managers at startup time, the context they would work in would be changed depending on what context instance it's passed in.

          Show
          Mircea Toma added a comment - - edited All these objects need access to objects that can be constructed only locally, such as PushContext or ServletContext. The managers should be changed so that they won't keep references to instances of ServletContext and such, but they would receive them when their methods are invoked. For example SessionViewManager.addView(String id) would be change to SessionViewManager.addView(String id, PushContext context) since the method uses internally PushContext class. Also the fields of the managers can be saved into a serializable structure (without behavior) and that will be saved into the session (thus session scoped). This approach will allow the creation of the managers at startup time, the context they would work in would be changed depending on what context instance it's passed in.
          Hide
          Mircea Toma added a comment -

          Removed obsolete org.icefaces.push.SessionRenderer API and implementation (not to be confused with the SessionRenderer API in "compat"). This API was used initailly for integrating ICEpush with ICEfaces. Later on was replaced by PushRenderer.

          Show
          Mircea Toma added a comment - Removed obsolete org.icefaces.push.SessionRenderer API and implementation (not to be confused with the SessionRenderer API in "compat"). This API was used initailly for integrating ICEpush with ICEfaces. Later on was replaced by PushRenderer.
          Hide
          Mircea Toma added a comment - - edited

          Refactored WindowScopeManager, SessionViewManager and LazyPushManager to save their serializable state in the session. Changed its methods to be stateless (and static), state is accessed and modified by these methods by looking it up from the session.

          Show
          Mircea Toma added a comment - - edited Refactored WindowScopeManager, SessionViewManager and LazyPushManager to save their serializable state in the session. Changed its methods to be stateless (and static), state is accessed and modified by these methods by looking it up from the session.
          Hide
          Mircea Toma added a comment -

          Created a separate issue for org.icefaces.push.DynamicResourceDispatcher refactoring since its resolution entails changes in the resource registration behavior: ICE-5848

          Show
          Mircea Toma added a comment - Created a separate issue for org.icefaces.push.DynamicResourceDispatcher refactoring since its resolution entails changes in the resource registration behavior: ICE-5848

            People

            • Assignee:
              Mircea Toma
              Reporter:
              Ted Goddard
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: