dev@glassfish.java.net

Startup time regression

From: Jerome Dochez <jerome.dochez_at_oracle.com>
Date: Fri, 3 Sep 2010 11:10:25 -0700

It's with great pleasure that I can start assigning to others my findings on why we regressed our startup time.

1] MonitoringBootstrap

Monitoring bootstrap code is probing any directory under lib/install/applications to resource adapters that may or may not contain flashlight probes. This cause the connector class loader to be created and cause a long list of modules to be resolved.

Solution : we should only probe RAs when they are deployed (used) rather than at startup.

Possible extended solution : we should extend that mechanism to all deployments so that any Java EE deployed application can ship probes and they would become automatically registered with our monitoring/REST tree. I am already drooling at the possibilities...
For that, it might be as simple as writing a ProbeDeployer.

I asked Mahesh to work with Jagadish on that.

2] Security

The security module is causing a number of modules to be resolved when the MasterPasswordImpl is looked up in the habitat from one of the Startup service. It would be great to not have that service packaged in the security module (I checked it has almost no dependency) so that its resolution does not cause the security module to be loaded.

owner : Kumar and Sahoo

3] javax.xml.rpc.handler

The security module resolution is eventually causing the following resolutions :

bundle ID bundle Name Imported packaged
220 security MasterPasswordImpl
158 interna-connector-api com.sun.appserv.connectors.internal-api.
69 dol com.sun.enterprise.deployment
220 org.glassfish.javax.ejb javax.interceptor
26 metro javax.xml.rpc.handler

The issue here is that even though bundle 220 packaged and exports javax.xml.rpc.handler, because metro has a bundle with a lower number (26 versus 220), the resolver is resolving the metro module to satisfy the import.

I need to work with Richard if it would be compatible with the OSGi specs that the resolver looks in the current module before resolving externally a package. this might still be an issue with Equinox obviously.

Another way would be to "install" the metro package last so its bundle ID is higher but that really seems like deferring the issue...

owner : Richard Hall and myself.

Once those 3 issues are fixed, we should see improvement in the startup time and we will reassess what modules are resolved at startup as the current issues are creating too much noise to assess the other potential issues.

jerome