glassfish
  1. glassfish
  2. GLASSFISH-6637

WebAppClassLoader.clearReferences() breaks running threads

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 9.1peur2
    • Fix Version/s: 9.1.1_dev
    • Component/s: web_container
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      6,637
    • Status Whiteboard:
      Hide

      gfv3-prelude-excluded, 911Approved

      Show
      gfv3-prelude-excluded, 911Approved

      Description

      Please reassign this to the appropriate subcomponent if needed.

      WebappClassLoader.clearReferences() breaks existing applications and there is no
      workaround. Please read these related bug reports:

      https://issues.apache.org/bugzilla/show_bug.cgi?id=41939
      https://issues.apache.org/bugzilla/show_bug.cgi?id=38579
      https://issues.apache.org/bugzilla/show_bug.cgi?id=27371
      https://issues.apache.org/bugzilla/show_bug.cgi?id=41059
      http://bugzilla.slf4j.org/show_bug.cgi?id=15

      There is a proposal at the bottom of
      https://issues.apache.org/bugzilla/show_bug.cgi?id=41059 that should fix this
      problem using a two-pass algorithm. Either way, please temporarily add a system
      property which allows users to disable this feature. Tomcat added
      -DENABLE_CLEAR_REFERENCES=false. I would encourage you to reuse this if possible.

        Activity

        Hide
        jluehe added a comment -

        Let's not go there.

        Going back to something you wrote earlier:

        The problem is that their algorithm nulls out field references as it
        encounters them, but as it walks from one class to another it
        sometimes triggers class initialization blocks. These, in turn, start
        invoking methods on classes that Tomcat has just destroyed and the
        resulting behavior is undefined (crashes may result)

        Why would that be so bad? The classes that may be initialized during this phase
        of the WebappClassLoader shutdown will be destroyed anyways, so why would it be
        important for them to initialize correctly? Do you see any sideeffects that
        would corrupt any classes other than the ones loaded by the WebappClassLoader
        being stopped?

        Thanks!

        Show
        jluehe added a comment - Let's not go there. Going back to something you wrote earlier: The problem is that their algorithm nulls out field references as it encounters them, but as it walks from one class to another it sometimes triggers class initialization blocks. These, in turn, start invoking methods on classes that Tomcat has just destroyed and the resulting behavior is undefined (crashes may result) Why would that be so bad? The classes that may be initialized during this phase of the WebappClassLoader shutdown will be destroyed anyways, so why would it be important for them to initialize correctly? Do you see any sideeffects that would corrupt any classes other than the ones loaded by the WebappClassLoader being stopped? Thanks!
        Hide
        cowwoc added a comment -

        You have no way of knowing what corrupt static initialization code might do. It
        might invoke some native code with unexpected values triggering some crash. It
        might invoke a method on a class from the shared ClassLoader and corrupt it in
        the process. The possibilities are limitless.

        Show
        cowwoc added a comment - You have no way of knowing what corrupt static initialization code might do. It might invoke some native code with unexpected values triggering some crash. It might invoke a method on a class from the shared ClassLoader and corrupt it in the process. The possibilities are limitless.
        Hide
        jluehe added a comment -

        Applied remaining patch (aka Curt's patch):

        Checking in WebappClassLoader.java;
        /cvs/glassfish/appserv-webtier/src/java/org/apache/catalina/loader/WebappClassLoader.java,v
        <-- WebappClassLoader.java
        new revision: 1.34.6.8; previous revision: 1.34.6.7
        done

        Show
        jluehe added a comment - Applied remaining patch (aka Curt's patch): Checking in WebappClassLoader.java; /cvs/glassfish/appserv-webtier/src/java/org/apache/catalina/loader/WebappClassLoader.java,v <-- WebappClassLoader.java new revision: 1.34.6.8; previous revision: 1.34.6.7 done
        Hide
        jluehe added a comment -

        Ported fix to GlassFish v3:

        Sending web/war-util/src/main/java/org/glassfish/web/loader/WebappClassLoader.java
        Transmitting file data .
        Committed revision 23608.

        Show
        jluehe added a comment - Ported fix to GlassFish v3: Sending web/war-util/src/main/java/org/glassfish/web/loader/WebappClassLoader.java Transmitting file data . Committed revision 23608.
        Hide
        jluehe added a comment -

        We have reports that the two-pass algorithm in
        WebappClassLoader#clearReferences, which is enabled by default, can still
        corrupt the server and cause it to crash, see
        https://glassfish.dev.java.net/issues/show_bug.cgi?id=10500

        The only way to successfully deploy and undeploy the app mentioned in that bug
        report is to disable the two-pass algorithm.

        Show
        jluehe added a comment - We have reports that the two-pass algorithm in WebappClassLoader#clearReferences, which is enabled by default, can still corrupt the server and cause it to crash, see https://glassfish.dev.java.net/issues/show_bug.cgi?id=10500 The only way to successfully deploy and undeploy the app mentioned in that bug report is to disable the two-pass algorithm.

          People

          • Assignee:
            jluehe
            Reporter:
            cowwoc
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: