glassfish
  1. glassfish
  2. GLASSFISH-20230

4.0 Deployment Performance - writing out domain.xml twice for one deployment

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 4.0_b83
    • Fix Version/s: 4.0_b85
    • Component/s: admin
    • Labels:
      None

      Description

      In GlassFish 4.0, the initial deployment of a simple web application (after a fresh installation, start domain and deploy) triggers the writing out of the domain.xml twice: the profile collected for GlassFish 4.0 have two invocations of DomainXmlPersistence.save (2 invocations) which took about 5.4% of overall deployment time; whereas in the profile collected for GlassFish 3.1.2, there is one invocation of DomainXmlPersistence.save which took about 3.4% of the time.

      In GlassFish 4.0, the first (extra) invocation happens in web container initialization:

      In appserver/web/jspcaching-connector/src/main/java/org/glassfish/jspcaching/integration/GlassFishTldProvider.java, postConstruct method

      WebContainer webContainer = cfg.getExtensionByType(WebContainer.class);

      Then this invokes

      ./nucleus/admin/config-api/src/main/java/com/sun/enterprise/config/modularity/parser/ModuleConfigurationLoader.java, createConfigBeanForType method which triggers the domain.xml writing.

      While this is part of the config modularity feature (aka zero config), based on the discussion with Tom, this should not produce a write of the domain.xml (these changes from config modularity should be just put in memory until there is another transaction that actually changes them).

      So we should investigate how we could elimiate this extra domain.xml writing.

      The second invocation is expected which happens at the end of the deployment to add the application related entries to the domain.xml.

      The other related thing I observed for server start up: in GlassFish 4.0, after I start domain with a fresh installation, the domain.xml.bak will be created. Whereas in GlassFish 3.1.2, I don't see domain.xml.bak get created after the domain is started. Tom confirmed he is seeing the same thing and we don't want to write the domain.xml when we start the server. So we should investigate how we could elimiate this domain.xml writing also.

        Activity

        Hide
        Masoud Kalali added a comment -
        • What is the impact on the customer of the bug? Deployment time is longer than expected.
        • How likely is it that a customer will see the bug and how serious is the bug? Customer would notice the change in application deployment time if they compare the time between 3.1.2 and 4.0.
        • Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)? It is a performance related bug.
        • What CTS failures are caused by this bug? No CTS is failing.
        • What is the cost/risk of fixing the bug? No risk, cost is very low.
        • How risky is the fix? How much work is the fix? Is the fix complicated? No risk and cost is very low, a fix is already devised and can be committed after approval process.
        • Is there an impact on documentation or message strings? No.
        • Which tests should QA (re)run to verify the fix did not destabilize GlassFish? None.
        • Which is the targeted build of 4.0 for this fix? 83
        • If this an integration of a new version of a component from another project, what are the changes that are being brought in? This might be list of Jira issues from that project or a list of revision messages.
        Show
        Masoud Kalali added a comment - What is the impact on the customer of the bug? Deployment time is longer than expected. How likely is it that a customer will see the bug and how serious is the bug? Customer would notice the change in application deployment time if they compare the time between 3.1.2 and 4.0. Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)? It is a performance related bug. What CTS failures are caused by this bug? No CTS is failing. What is the cost/risk of fixing the bug? No risk, cost is very low. How risky is the fix? How much work is the fix? Is the fix complicated? No risk and cost is very low, a fix is already devised and can be committed after approval process. Is there an impact on documentation or message strings? No. Which tests should QA (re)run to verify the fix did not destabilize GlassFish? None. Which is the targeted build of 4.0 for this fix? 83 If this an integration of a new version of a component from another project, what are the changes that are being brought in? This might be list of Jira issues from that project or a list of revision messages.
        Hide
        Hong Zhang added a comment -

        Masoud: thanks for the quick turn around! Will you fix address the initial deployment and also the issue reported for server start up?

        Show
        Hong Zhang added a comment - Masoud: thanks for the quick turn around! Will you fix address the initial deployment and also the issue reported for server start up?
        Hide
        Tom Mueller added a comment -

        The initial domain.xml.bak file is created the first time the domain is started as a result of the following modifications to the configuration:

        • managed-job-config
        • batch-runtime-configuration
        • jms-service
        • connector-connection-pool
        • connector-resource
        • resource-ref

        These configuration modifications cause the domain.xml to written 6 times, once for each transaction.
        Since these changes are written to the domain.xml file, these transactions are not repeated the next time the server is started. However, if these 6 writes are avoided, then these 6 transactions will need to be repeated for every server start, so that may have a performance impact.

        So the real concern is the writing of the domain.xml during application deployment. These writes are the result of the following modifications to the configuration:

        • cdi-service
        • web-container
        • 29 changes related to deploying the application

        So there are actually 3 writes in 4.0 rather than the 1 write in 3.1.2. Eliminating the writes due to the config modularity changes will correct this problem.

        However, if the cdi-service and web-container elements are never written to the domain.xml, then those two transactions will need to be repeated each time the server is started which might have a performance impact.

        Show
        Tom Mueller added a comment - The initial domain.xml.bak file is created the first time the domain is started as a result of the following modifications to the configuration: managed-job-config batch-runtime-configuration jms-service connector-connection-pool connector-resource resource-ref These configuration modifications cause the domain.xml to written 6 times, once for each transaction. Since these changes are written to the domain.xml file, these transactions are not repeated the next time the server is started. However, if these 6 writes are avoided, then these 6 transactions will need to be repeated for every server start, so that may have a performance impact. So the real concern is the writing of the domain.xml during application deployment. These writes are the result of the following modifications to the configuration: cdi-service web-container 29 changes related to deploying the application So there are actually 3 writes in 4.0 rather than the 1 write in 3.1.2. Eliminating the writes due to the config modularity changes will correct this problem. However, if the cdi-service and web-container elements are never written to the domain.xml, then those two transactions will need to be repeated each time the server is started which might have a performance impact.
        Hide
        Tom Mueller added a comment -

        Fixed in revision 61422.

        Show
        Tom Mueller added a comment - Fixed in revision 61422.

          People

          • Assignee:
            Tom Mueller
            Reporter:
            Hong Zhang
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: