glassfish
  1. glassfish
  2. GLASSFISH-17038

3.1.1 deployment performance - ejb container module get loaded for a pure web application

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.1
    • Fix Version/s: 3.1.2.2
    • Component/s: ejb_container
    • Labels:
      None

      Description

      Using the felix console to monitor which module get loaded for the web application deployment, noticed the ejb container module got active and the ejb security module got resolved

      208|Active | 1|org.glassfish.ejb.ejb-container (3.1.1.SNAPSHOT)

      94|Resolved | 1|org.glassfish.security.ejb.security (3.1.1.SNAPSHOT)

      we need to figure out which dependency had triggered the ejb related modules get loaded/resolved, they should not be for a pure web application. I will attach the test web application in the issue next.

        Issue Links

          Activity

          Hide
          Hong Zhang added a comment -

          please see its parent issue for the test application

          Show
          Hong Zhang added a comment - please see its parent issue for the test application
          Hide
          Hong Zhang added a comment -

          Further analysis showed the ejb-container jar was loaded as part of the web container initialization. And also ejb-container contains implementation classes of AnnotationHandler which will be brought in by dol module as well (SJSASFactory injects a list of AnnotationHandler classes)

          -----------------------------------
          Inhabitants / stack combination
          -----------------------------------
          Requested by LazyInhabitant-13768021(com.sun.ejb.base.io.JavaEEIOUtilsImpl, active: null) called from org.glassfish.internal.data.EngineInfo.getContainer:93 metadata

          {class: [com.sun.ejb.base.io.JavaEEIOUtilsImpl] index: [com.sun.enterprise.container.common.spi.util.JavaEEIOUtils] }

          Requested by ConstructorCreator-29633611(com.sun.enterprise.web.WebContainer) called from org.glassfish.internal.data.EngineInfo.getContainer:93 metadata

          {class: [com.sun.enterprise.web.WebContainer] org.glassfish.api.container.Container: [com.sun.enterprise.web.WebContainer] index: [org.glassfish.api.container.Container:com.sun.enterprise.web.WebContainer] }
          Show
          Hong Zhang added a comment - Further analysis showed the ejb-container jar was loaded as part of the web container initialization. And also ejb-container contains implementation classes of AnnotationHandler which will be brought in by dol module as well (SJSASFactory injects a list of AnnotationHandler classes) ----------------------------------- Inhabitants / stack combination ----------------------------------- Requested by LazyInhabitant-13768021(com.sun.ejb.base.io.JavaEEIOUtilsImpl, active: null) called from org.glassfish.internal.data.EngineInfo.getContainer:93 metadata {class: [com.sun.ejb.base.io.JavaEEIOUtilsImpl] index: [com.sun.enterprise.container.common.spi.util.JavaEEIOUtils] } Requested by ConstructorCreator-29633611(com.sun.enterprise.web.WebContainer) called from org.glassfish.internal.data.EngineInfo.getContainer:93 metadata {class: [com.sun.enterprise.web.WebContainer] org.glassfish.api.container.Container: [com.sun.enterprise.web.WebContainer] index: [org.glassfish.api.container.Container:com.sun.enterprise.web.WebContainer] }
          Hide
          marina vatkina added a comment -

          Hong,

          As you can see, AnnotationHandler's everywhere cause corresponding modules to be loaded. Unless all of them are moved to the modules with Sniffers, there is not much that our modules can do.

          Show
          marina vatkina added a comment - Hong, As you can see, AnnotationHandler's everywhere cause corresponding modules to be loaded. Unless all of them are moved to the modules with Sniffers, there is not much that our modules can do.
          Hide
          Hong Zhang added a comment -

          yes, several areas have similar issue and I am looking for a uniformed solution. Moved to the connector module with sniffer is one possibility. I will keep you posted. I am keeping this issue under ejb-container for now as the code to be moved here will be ejb related.

          Show
          Hong Zhang added a comment - yes, several areas have similar issue and I am looking for a uniformed solution. Moved to the connector module with sniffer is one possibility. I will keep you posted. I am keeping this issue under ejb-container for now as the code to be moved here will be ejb related.
          Hide
          Hong Zhang added a comment -

          Aside from the AnnotationHandler related issues, let's look at the first one (current one) to bring in the ejb-container module.

          According to the HK2 traces (attached in the issue), the ejb-container is brought in as part of the web container initialization. And further look at the WebContainer code, there is this injection:
          @Inject
          private JavaEEIOUtils javaEEIOUtils

          This injection loads its impl class JavaEEIOUtilsImpl in the ejb-container module (ejb/ejb-container/src/main/java/com/sun/ejb/base/io/JavaEEIOUtilsImpl.java) which makes the ejb-container module loaded.

          Assign to web container for initial evaluation on this issue, to see why the web container needs to use this class, and then how we can resolve the issue (maybe moving the JavaEEIOUtilsImpl.java to one of the common modules like container-common or common-utils).

          Once we get this dependency removed, we can look at the annotation handlers related things.

          Show
          Hong Zhang added a comment - Aside from the AnnotationHandler related issues, let's look at the first one (current one) to bring in the ejb-container module. According to the HK2 traces (attached in the issue), the ejb-container is brought in as part of the web container initialization. And further look at the WebContainer code, there is this injection: @Inject private JavaEEIOUtils javaEEIOUtils This injection loads its impl class JavaEEIOUtilsImpl in the ejb-container module (ejb/ejb-container/src/main/java/com/sun/ejb/base/io/JavaEEIOUtilsImpl.java) which makes the ejb-container module loaded. Assign to web container for initial evaluation on this issue, to see why the web container needs to use this class, and then how we can resolve the issue (maybe moving the JavaEEIOUtilsImpl.java to one of the common modules like container-common or common-utils). Once we get this dependency removed, we can look at the annotation handlers related things.
          Hide
          Shing Wai Chan added a comment -

          Web container uses JavaEEIOUtils in order to serialize and deserialize the EJB references in HttpSession correctly.
          Assign to ejb container to see whether this implementation can be moved to a common module.

          Show
          Shing Wai Chan added a comment - Web container uses JavaEEIOUtils in order to serialize and deserialize the EJB references in HttpSession correctly. Assign to ejb container to see whether this implementation can be moved to a common module.
          Hide
          marina vatkina added a comment -

          There are 2 issues reported here:

          AnnotationHandlers location. This works as designed.

          JavaEEIOUtils dependencies - there is already an RFE for moving them to the common location: http://java.net/jira/browse/GLASSFISH-13973

          Show
          marina vatkina added a comment - There are 2 issues reported here: AnnotationHandlers location. This works as designed. JavaEEIOUtils dependencies - there is already an RFE for moving them to the common location: http://java.net/jira/browse/GLASSFISH-13973
          Hide
          Hong Zhang added a comment -

          Marina:
          1. For annotation handlers issue, even though it's expected behavior with the current HK2 mechanism to find the impl classes from various modules. But this does not mean we should load the ejb-container module because of this. We need to move these handlers classes to another module to avoid loading ejb-container module as part of the web deployment.
          2. For JavaEEIOUtils.java, I understand this is already a RFE filed it, but as we are now really looking for performance gain, we should continue looking into this:
          a. can we verify the dynamic injection indeed does not work?
          b. what about my suggestion of moving the relevant classes to ejb-connector module?

          As the performance is the release priority now, I am re-opening the issue now to request further investigation. Thanks for your understanding.

          Show
          Hong Zhang added a comment - Marina: 1. For annotation handlers issue, even though it's expected behavior with the current HK2 mechanism to find the impl classes from various modules. But this does not mean we should load the ejb-container module because of this. We need to move these handlers classes to another module to avoid loading ejb-container module as part of the web deployment. 2. For JavaEEIOUtils.java, I understand this is already a RFE filed it, but as we are now really looking for performance gain, we should continue looking into this: a. can we verify the dynamic injection indeed does not work? b. what about my suggestion of moving the relevant classes to ejb-connector module? As the performance is the release priority now, I am re-opening the issue now to request further investigation. Thanks for your understanding.
          Hide
          marina vatkina added a comment -

          Hong,

          As the investigation for the Annotation handlers needs to be done at the GF level, I'll reassign this bug to you. When the decision is made on what is the approach to be taken GF-wide, feel free to reassign it back to us.

          Show
          marina vatkina added a comment - Hong, As the investigation for the Annotation handlers needs to be done at the GF level, I'll reassign this bug to you. When the decision is made on what is the approach to be taken GF-wide, feel free to reassign it back to us.
          Hide
          Hong Zhang added a comment -

          Marina: I had discussed with Jerome yesterday. Between the two options of moving the classes back to DOL versus creating a new glue module to hold the classes, he prefers to have a new module.

          Show
          Hong Zhang added a comment - Marina: I had discussed with Jerome yesterday. Between the two options of moving the classes back to DOL versus creating a new glue module to hold the classes, he prefers to have a new module.
          Hide
          marina vatkina added a comment -

          Hong,

          Did you discuss this at asarch?

          Show
          marina vatkina added a comment - Hong, Did you discuss this at asarch?
          Hide
          Hong Zhang added a comment -

          I am not sure that this change requires asarch discussion, we should just not load ejb-container module as part of the web deployment, right? But if you think it's necessary, you can start a thread with asarch and Cc me. Thanks.

          Show
          Hong Zhang added a comment - I am not sure that this change requires asarch discussion, we should just not load ejb-container module as part of the web deployment, right? But if you think it's necessary, you can start a thread with asarch and Cc me. Thanks.
          Hide
          marina vatkina added a comment -

          According to Scott it's no longer critical

          Show
          marina vatkina added a comment - According to Scott it's no longer critical
          Hide
          Cheng Fang added a comment - - edited

          committed Rev: 48926 to 3.1.2 branch, moving annotation handler classes, archivist class, scanner class, and the related from ejb-container to ejb-connector.

          committed revision 48934 to trunk.

          Show
          Cheng Fang added a comment - - edited committed Rev: 48926 to 3.1.2 branch, moving annotation handler classes, archivist class, scanner class, and the related from ejb-container to ejb-connector. committed revision 48934 to trunk.
          Hide
          Cheng Fang added a comment -

          With the above fix and when web container obtains JavaEEIOUtils lazily, or when web container uses a generic JavaEEIOUtils impl, ejb container will not be loaded when deploying servlet/jsp-based web app.

          For jsf-based app, the lookup by jsf impl of "clientStateSavingPassword" will trigger the loading of global NamedNamingProxy, which includes EJBContext. As a result, ejb-container will be loaded. This naming proxy bootstrapping happens prior to the first lookup operation, and in this case jsf happens to perform the first lookup.

          Show
          Cheng Fang added a comment - With the above fix and when web container obtains JavaEEIOUtils lazily, or when web container uses a generic JavaEEIOUtils impl, ejb container will not be loaded when deploying servlet/jsp-based web app. For jsf-based app, the lookup by jsf impl of "clientStateSavingPassword" will trigger the loading of global NamedNamingProxy, which includes EJBContext. As a result, ejb-container will be loaded. This naming proxy bootstrapping happens prior to the first lookup operation, and in this case jsf happens to perform the first lookup.
          Hide
          Cheng Fang added a comment -

          In 4.0 trunk only, ejb-related annotation handler classes are moved back to ejb-container. See issue http://java.net/jira/browse/GLASSFISH-17988 (move ejb annotation handlers out of ejb-connector)

          Show
          Cheng Fang added a comment - In 4.0 trunk only, ejb-related annotation handler classes are moved back to ejb-container. See issue http://java.net/jira/browse/GLASSFISH-17988 (move ejb annotation handlers out of ejb-connector)
          Hide
          Hong Zhang added a comment -

          I just checked this for 3.1.2.2 and ejb container is no longer loaded (in active state) after deployment.

          Show
          Hong Zhang added a comment - I just checked this for 3.1.2.2 and ejb container is no longer loaded (in active state) after deployment.

            People

            • Assignee:
              marina vatkina
              Reporter:
              Hong Zhang
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: