Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.2.9-core
    • Fix Version/s: 1.2.10-core
    • Component/s: Archetype
    • Labels:
      None
    • Environment:
      All

      Description

      Most Servlet Engines support fail over for high availability by replicating changes the the Session state to other servers. This requires that all of the state and substate in the Session be Serializable. If the state is not Serializable, the failover will fail with a SerializationException and most likely the Session attribute key for which Serialization failed. This poses several problems for framework and application developers:
      1) An actual high-availability configuration should not be necessary to test that the framework and application is using Session state correctly
      2) The Servlet specification requires that an exception be thrown immediately when adding setting a non Serializable attribute on the Session when the Servlet engine is running in high-availibility mode. This enables the offending code to be quickly identified for simple case, but this requires:
      a) That the server be running in such a mode, which may be a pain to configure
      b) Some Servlet engines don't implement this feature
      3) Knowing the offending key in the Session state is not very useful if the value of the key is an extremely complicated structure. In particular, determining precisely which attribute value on which component in the component state structure used in Trinidad state saving is a nightmare.

      The proposal is to address the problems by:
      1) Making it possible to run Trinidad in a mode where unserializable state content and sets on Session attributes are detected
      2) When a state Serialization failure is detected, more detailed failure information regarding the component and attribute key and value that failed can be determined by rerunning with additional, but slower settings

      In order to decrease runtime overhead, the proposal is that a System property:

      org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION

      is used to control this behavior as this allows the behavior to be determined a class load time.

      The behavior is controlled by passing a comma-delimited set of case-insensitive values on the system property:
      NONE--no state serialization checks are performed (the default)
      ALL--perform all available tests (unless NONE is also specified, in which case NONE takes precedence)
      SESSION-Wrap the Session Map returned by the ExternalContext to test that only Serializable objects are placed in the Session Map, throwing a CastCastException if the Object is not Serializable
      TREE--aggressively attempt to serialize the component state during state saving and throw an exception if serialization fails
      COMPONENT--aggressively attempt to serialize each component subtree's state during state saving in order to identify the problem component (slow)
      PROPERTY--aggessively attempt to serialize each property value during state saving in order to identify the problem property (slow)

      For high availability testing, the tester would initially start off validating the Session and JSF state is Serializable by setting the system property to:
      -Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree

      If a JSF state serialization is detected, the test is rerun with the component and property flags enabled:
      -Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all

      Programmatic access to these flags would be on the StateUtils class:

      /**

      • Returns <code>true</code> if components should be checked for
      • serializability when when generating the view's state object.
      • <p>
      • By default component state serialization checking is off. It can be
      • enabled by setting the system property
      • <code>org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION</code>
      • to <code>all</code> or, more rarely, adding <code>component</code> to the
      • comma-separated list of serialization checks to perform.
      • <p>
      • As property serialization checking is expensive, it is usually
      • only enabled after component tree serialization checking has detected
      • a problem. In addition, since component serialization checking only
      • detects the problem component, it is usually combined with
      • property state serialization checking either by specifying <code>all</code>.
      • @return
      • @see #checkComponentTreeStateSerialization
        */
        public static boolean checkComponentStateSerialization(FacesContext context)

      /**

      • Returns <code>true</code> if the component tree should be checked for
      • serializability when when generating the view's state object.
      • <p>
      • By default component tree state serialization checking is off. It can be
      • enabled by setting the system property
      • <code>org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION</code>
      • to <code>all</code> or, more commonly, adding <code>tree</code> to the
      • comma-separated list of serialization checks to perform.
      • <p>
      • Because unserializable objects defeat fail-over, it is important to
      • check for serializability when testing applications. While component
      • tree state serializability checking isn't cheap, it is much faster to
      • initially only enable checking of the component tree and then switch
      • to <code>all</code> testing to determine the problem component and
      • property when the component tree testing determines a problem.
      • @return
      • @see #checkComponentStateSerialization
        */
        public static boolean checkComponentTreeStateSerialization(FacesContext context)

      /**

      • Returns <code>true</code> if Object written to the SessionMap should be checked for
      • Serializability when <code>put</code> is called.
      • <p>
      • Configuring this property allows this aspect of high-availability to be tested without
      • configuring the server to run in high-availability mode.
      • <p>
      • By default session serialization checking is off. It can be
      • enabled by setting the system property
      • <code>org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION</code>
      • to <code>all</code> or, more commonly, adding <code>session</code> to the
      • comma-separated list of serialization checks to perform.
      • @return
      • @see #checkComponentStateSerialization
      • @see #checkComponentTreeStateSerialization
        */
        public static boolean checkSessionSerialization(ExternalContext extContext)

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        2d 3h 26m 1 Matthias Weßendorf 03/Oct/08 11:43
        Resolved Resolved Closed Closed
        480d 22h 2m 1 Matthias Weßendorf 27/Jan/10 08:46
        Matthias Weßendorf made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Matthias Weßendorf made changes -
        Assignee Matthias Weßendorf [ matzew ]
        Fix Version/s 1.2.10-core [ 12313342 ]
        Resolution Fixed [ 1 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Blake Sullivan made changes -
        Field Original Value New Value
        Attachment Trin1245_1_2_TRUNK.patch [ 12391268 ]
        Hide
        Blake Sullivan added a comment -

        Patch for issue 1245 against 1.2 Trunk.
        Path also contains CollectionUtils class for generating lazily Serialized copies of unserialiable lists, like the ones returned by AbstractList.subList().

        Show
        Blake Sullivan added a comment - Patch for issue 1245 against 1.2 Trunk. Path also contains CollectionUtils class for generating lazily Serialized copies of unserialiable lists, like the ones returned by AbstractList.subList().
        Blake Sullivan created issue -

          People

          • Assignee:
            Matthias Weßendorf
            Reporter:
            Blake Sullivan
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 168h
              168h
              Remaining:
              Remaining Estimate - 168h
              168h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development