glassfish
  1. glassfish
  2. GLASSFISH-20386

Deployment is slow because of WebappClassLoader.extractResource

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.1, 3.1.2, 3.1.2.2
    • Fix Version/s: 4.1
    • Component/s: web_container
    • Labels:
      None

      Description

      Web application deployment and redeployment is very slow when compared with Tomcat, especially on Windows.

      It's to the point where several of my team members are actively looking to avoid Java EE technologies, specifically so they can develop entirely within Tomcat.

      With profiling and Java VisualVM I was able to isolate the problem to WebappClassLoader, which appears to unpack all the JARs in WEB-INF/lib.

      And within that operation, the call to getCanonicalPath for each JAR entry for validation appears to be the bulk of the problem.

      It is especially acute on Windows, leading to the paradox that running Glassfish in a Linux VM is faster than running natively on Windows on the same hardware

      Is there any way to optimize this?

      Two suggestions:

      • avoid pre-emptively unpacking all the JARs
      • come up with a simpler validation check for JAR entries that doesn't rely on getCanonicalPath (e.g., ensure string only could be translated to a legal Java fully-qualified identifier)

        Issue Links

          Activity

          Hide
          Sanjeeb Sahoo added a comment -

          I have created GLASSFISH-20593 to capture the regression in osgi web container.

          Show
          Sanjeeb Sahoo added a comment - I have created GLASSFISH-20593 to capture the regression in osgi web container.
          Hide
          Shing Wai Chan added a comment -

          Before the fix, in StandardContext#getResource, when resources.lookup fails, getMetaInfResource(path) is invoked and WebappClassloader.getResourceFromJars(path) is called.
          In OSGi environment, the above method is override in OSGiWebDeploymentContext.WEBClassLoader which will do an additional resources lookup in META-INF/resources (even not in WEB-INF/lib/*.jar).

          In the fix, we encapsulate looking up resource of WEB-INF/lib/*.jar within resources.lookup. And the call of getMetaInfResource(path) (and WebappClassloader.getResourceFromJars(path) are removed. Hence the OSGiWebDeploymentContext.WEBClassLoader.getResourceFromJars is not invoked.

          The OSGiWebDeploymentContext.WEBClassLoader.getResource should be fixed to include the additional lookup of META-INF/resources with the OSGi modules.

          Show
          Shing Wai Chan added a comment - Before the fix, in StandardContext#getResource, when resources.lookup fails, getMetaInfResource(path) is invoked and WebappClassloader.getResourceFromJars(path) is called. In OSGi environment, the above method is override in OSGiWebDeploymentContext.WEBClassLoader which will do an additional resources lookup in META-INF/resources (even not in WEB-INF/lib/*.jar). In the fix, we encapsulate looking up resource of WEB-INF/lib/*.jar within resources.lookup. And the call of getMetaInfResource(path) (and WebappClassloader.getResourceFromJars(path) are removed. Hence the OSGiWebDeploymentContext.WEBClassLoader.getResourceFromJars is not invoked. The OSGiWebDeploymentContext.WEBClassLoader.getResource should be fixed to include the additional lookup of META-INF/resources with the OSGi modules.
          Hide
          Sanjeeb Sahoo added a comment -

          This fix has caused regression in OSGi/Web container area related WAB fragments.

          Show
          Sanjeeb Sahoo added a comment - This fix has caused regression in OSGi/Web container area related WAB fragments.
          Hide
          Shing Wai Chan added a comment -

          Sending war-util/src/main/java/com/sun/enterprise/glassfish/web/WarHandler.java
          Sending war-util/src/main/java/org/glassfish/web/loader/WebappClassLoader.java
          Sending web-core/src/main/java/org/apache/catalina/core/StandardContext.java
          Sending web-core/src/main/java/org/apache/catalina/loader/WebappLoader.java
          Sending web-core/src/main/java/org/apache/catalina/servlets/DefaultServlet.java
          Adding web-naming/src/main/java/org/apache/naming/resources/JarFileResourcesProvider.java
          Adding web-naming/src/main/java/org/apache/naming/resources/WebDirContext.java
          Transmitting file data .......
          Committed revision 62087.

          Show
          Shing Wai Chan added a comment - Sending war-util/src/main/java/com/sun/enterprise/glassfish/web/WarHandler.java Sending war-util/src/main/java/org/glassfish/web/loader/WebappClassLoader.java Sending web-core/src/main/java/org/apache/catalina/core/StandardContext.java Sending web-core/src/main/java/org/apache/catalina/loader/WebappLoader.java Sending web-core/src/main/java/org/apache/catalina/servlets/DefaultServlet.java Adding web-naming/src/main/java/org/apache/naming/resources/JarFileResourcesProvider.java Adding web-naming/src/main/java/org/apache/naming/resources/WebDirContext.java Transmitting file data ....... Committed revision 62087.
          Hide
          wrschneider99 added a comment -

          Not extracting in the first place would be preferable, because you'd get a bigger improvement by using the JARs in place rather than extracting. File I/O on Windows is slower than on Linux/UNIX platforms. Also it can be impacted heavily by antivirus.

          Show
          wrschneider99 added a comment - Not extracting in the first place would be preferable, because you'd get a bigger improvement by using the JARs in place rather than extracting. File I/O on Windows is slower than on Linux/UNIX platforms. Also it can be impacted heavily by antivirus.
          Hide
          Shing Wai Chan added a comment -

          If we extract resources, the #getCanonicalPath is necessary in this case. We are working on having extraction configurable.

          Show
          Shing Wai Chan added a comment - If we extract resources, the #getCanonicalPath is necessary in this case. We are working on having extraction configurable.
          Hide
          Hong Zhang added a comment -

          As this code is in WebappClassLoader, assign to Shingwai to see if we can change the getName to getCanonicalPath..

          Show
          Hong Zhang added a comment - As this code is in WebappClassLoader, assign to Shingwai to see if we can change the getName to getCanonicalPath..
          Hide
          Scott Oaks added a comment -

          Really, I suspect the underlying issue is the performance of getCanonicalPath on Windows given that the windows file system is not particularly fast (nor programmer-friendly). It's actually not surprising to me that a Linux VM could out-perform a Windows native app when the performance is dependent on OS-provided services.

          I will pursue the JDK topic with the JDK group, though I doubt there is much they can do. Meanwhile, reassigning to Hong to see if we could use getName() instead of getCanonicalPath().

          Show
          Scott Oaks added a comment - Really, I suspect the underlying issue is the performance of getCanonicalPath on Windows given that the windows file system is not particularly fast (nor programmer-friendly). It's actually not surprising to me that a Linux VM could out-perform a Windows native app when the performance is dependent on OS-provided services. I will pursue the JDK topic with the JDK group, though I doubt there is much they can do. Meanwhile, reassigning to Hong to see if we could use getName() instead of getCanonicalPath().

            People

            • Assignee:
              Shing Wai Chan
              Reporter:
              wrschneider99
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: