Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8DR#1
    • Fix Version/s: 1.8DR#2, 1.8
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      JSF 1.2, component-showcase, both synchronous mode and asynchronous mode

      Description

      I think that we have a problem with our state saving. I took some code from Sun's StateManagerImpl, where it restores the view, to see how it accesses the saved state. I noticed that, for subsequent post-backs to a single view, we appear to be accumulating saved state into the session.

      I added the following lines to the end of D2DViewHandler.writeState(FacesContext):

      // javax.faces.render.ResponseStateManager.VIEW_STATE_PARAM
      String ResponseStateManager__VIEW_STATE_PARAM = "javax.faces.ViewState";
      Object pValue = context.getExternalContext().
          getRequestParameterMap().get(ResponseStateManager__VIEW_STATE_PARAM);
      System.out.println("pValue: " + pValue);

      // The value com.sun.faces.application.StateManagerImpl uses
      String LOGICAL_VIEW_MAP = "com.sun.faces." + "logicalViewMap";
      Map logicalMap = (Map) context.getExternalContext().getSessionMap().get(LOGICAL_VIEW_MAP);
      System.out.println("logicalMap: " + logicalMap);

      I then clicked around in the component showcase several times, each time it printed out two lines:

      pValue: j_id1:j_id2
      logicalMap: {j_id1={j_id2=[Ljava.lang.Object;@f036de, j_id3=[Ljava.lang.Object;@c50443}}

      pValue: j_id1:j_id2
      logicalMap: {j_id1={j_id3=[Ljava.lang.Object;@c50443, j_id2=[Ljava.lang.Object;@f036de, j_id4=[Ljava.lang.Object;@1a6d5e1}}

      pValue: j_id1:j_id2
      logicalMap: {j_id1={j_id3=[Ljava.lang.Object;@c50443, j_id4=[Ljava.lang.Object;@1a6d5e1, j_id2=[Ljava.lang.Object;@f036de, j_id
      5=[Ljava.lang.Object;@c5c0e5}}

      pValue: j_id1:j_id2
      logicalMap: {j_id1={j_id3=[Ljava.lang.Object;@c50443, j_id4=[Ljava.lang.Object;@1a6d5e1, j_id5=[Ljava.lang.Object;@c5c0e5, j_id
      2=[Ljava.lang.Object;@f036de, j_id6=[Ljava.lang.Object;@1e1dfb2}}

      pValue: j_id1:j_id2
      logicalMap: {j_id1={j_id3=[Ljava.lang.Object;@c50443, j_id4=[Ljava.lang.Object;@1a6d5e1, j_id5=[Ljava.lang.Object;@c5c0e5, j_id
      6=[Ljava.lang.Object;@1e1dfb2, j_id2=[Ljava.lang.Object;@f036de, j_id7=[Ljava.lang.Object;@163058b}}

      pValue: j_id1:j_id2
      logicalMap: {j_id1={j_id3=[Ljava.lang.Object;@c50443, j_id4=[Ljava.lang.Object;@1a6d5e1, j_id5=[Ljava.lang.Object;@c5c0e5, j_id
      6=[Ljava.lang.Object;@1e1dfb2, j_id7=[Ljava.lang.Object;@163058b, j_id2=[Ljava.lang.Object;@f036de, j_id8=[Ljava.lang.Object;@15fd309}}

      pValue: j_id1:j_id2
      logicalMap: {j_id1={j_id3=[Ljava.lang.Object;@c50443, j_id4=[Ljava.lang.Object;@1a6d5e1, j_id5=[Ljava.lang.Object;@c5c0e5, j_id
      6=[Ljava.lang.Object;@1e1dfb2, j_id7=[Ljava.lang.Object;@163058b, j_id8=[Ljava.lang.Object;@15fd309, j_id2=[Ljava.lang.Object;@f036de, j_id9=[Ljava.lang.Ob
      ject;@1b8c5e3}}

        Issue Links

          Activity

          Hide
          Mark Collette added a comment -

          The number of entries is limited to the most recent 15, which I think is JSF default limit for number of views in a session.

          Show
          Mark Collette added a comment - The number of entries is limited to the most recent 15, which I think is JSF default limit for number of views in a session.
          Hide
          Mark Collette added a comment -

          The regular Sun code synchronizes on the session object when accessing the session map. This sample code doesn't do that, but I've only ran it with a single view, so it shouldn't be a problem for this Jira. It might explain some of the weirdness for ICE-3842, since that does lifecycles on another thread. But even then, I don't think things would overlap.

          Show
          Mark Collette added a comment - The regular Sun code synchronizes on the session object when accessing the session map. This sample code doesn't do that, but I've only ran it with a single view, so it shouldn't be a problem for this Jira. It might explain some of the weirdness for ICE-3842 , since that does lifecycles on another thread. But even then, I don't think things would overlap.
          Hide
          Greg Dick added a comment -

          This may be an issue with the JSF implementation. In a simple testcase I see the same behaviour in pure JSF. A search through the codebase shows no resetting of the session based LRUMap. From the JSF source

          // Server Side state saving is handled stored in two nested LRU maps
          // in the session.
          //
          // The first map is called the LOGICAL_VIEW_MAP. A logical view
          // is a top level view that may have one or more actual views inside
          // of it. This will be the case when you have a frameset, or an
          // application that has multiple windows operating at the same time.
          // The LOGICAL_VIEW_MAP map contains
          // an entry for each logical view, up to the limit specified by the
          // numberOfViewsParameter. Each entry in the LOGICAL_VIEW_MAP
          // is an LRU Map, configured with the numberOfViewsInLogicalView
          // parameter.
          //
          // The motivation for this is to allow better memory tuning for
          // apps that need this multi-window behavior.

          I'm not sure it's actually being implemented like that. The logging output seems to show increasing hashmap contents for a given view rather than the capability to store a single key for multiple views.

          In any event, this behaviour is in common JSF code that we invoke from our instance of ViewHandler, and the object synchronization mentioned above is also contained within the JSF code we invoke. At this stage, I don't think there's anything wrong with the state saving implementation.

          Show
          Greg Dick added a comment - This may be an issue with the JSF implementation. In a simple testcase I see the same behaviour in pure JSF. A search through the codebase shows no resetting of the session based LRUMap. From the JSF source // Server Side state saving is handled stored in two nested LRU maps // in the session. // // The first map is called the LOGICAL_VIEW_MAP. A logical view // is a top level view that may have one or more actual views inside // of it. This will be the case when you have a frameset, or an // application that has multiple windows operating at the same time. // The LOGICAL_VIEW_MAP map contains // an entry for each logical view, up to the limit specified by the // numberOfViewsParameter. Each entry in the LOGICAL_VIEW_MAP // is an LRU Map, configured with the numberOfViewsInLogicalView // parameter. // // The motivation for this is to allow better memory tuning for // apps that need this multi-window behavior. I'm not sure it's actually being implemented like that. The logging output seems to show increasing hashmap contents for a given view rather than the capability to store a single key for multiple views. In any event, this behaviour is in common JSF code that we invoke from our instance of ViewHandler, and the object synchronization mentioned above is also contained within the JSF code we invoke. At this stage, I don't think there's anything wrong with the state saving implementation.
          Hide
          Mark Collette added a comment -

          Perhaps, for this Jira, we should bring our findings to the attention of the Mojarra team, by filing a bug entry in their system, showing the behaviour in the stock JSF application.

          Show
          Mark Collette added a comment - Perhaps, for this Jira, we should bring our findings to the attention of the Mojarra team, by filing a bug entry in their system, showing the behaviour in the stock JSF application.
          Hide
          Greg Dick added a comment - - edited

          JSF is keeping a history of the state saved views for back button navigation. On pressing the back button, the browser will replace the current page with a historical version of the page without any server interaction, and the old viewState keys are still valid - up to 15, which is the compile time limit on the LinkedHashMap that contains them.

          There is a run time context param that defines how large this map is to be.
          com.sun.faces.numberOfLogicalViews

          Show
          Greg Dick added a comment - - edited JSF is keeping a history of the state saved views for back button navigation. On pressing the back button, the browser will replace the current page with a historical version of the page without any server interaction, and the old viewState keys are still valid - up to 15, which is the compile time limit on the LinkedHashMap that contains them. There is a run time context param that defines how large this map is to be. com.sun.faces.numberOfLogicalViews

            People

            • Assignee:
              Unassigned
              Reporter:
              Mark Collette
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: