Posted by binod
on September 2, 2005 at 10:17 AM PDT
This is my first ever blog. I got many e-mails recently, asking me details about a feature called on-demand initialization (or lazy initialization) in Sun Java System Application Server or GlassFish (http://glassfish.dev.java.net ) and I thought I could use this blog post to explain what it is all about.
This is my first ever blog. I am basically a developer/engineer by profession (not a writer). So, please don't expect my blogs to be anywhere near an organized reading material.
Lets come to the topic.
I got many e-mails recently, asking me details about a feature called on-demand initialization (or lazy initialization) in Sun Java System Application Server or GlassFish ... and I thought I could use this blog post to explain what it is all about.
What does this feature accomplish?
After this feature is implemented, the actual startup time for Application Server became nearly half of what it was in its previous version. The memory footprint has also reduced a lot. See Peter's blog about his experience
Why was it taking longer to startup earlier?
In my mind, Java EE is a mature and really capable technology for enterprise applications. As an Application Server compliant to Java EE, GlassFish supports many technologies or services specified in the Java EE specification. Lets try to name a few of them... Servlet, JSP, Webservices, EJB, JMS, Connectors, JDBC, JMX, JSF....
Application server, on startup, initialize containers/components that provide these services eagerly and this takes a long time AND lot of memory.
So, what does this new feature do?
Most of the developers are not going to use all the services in the Application Server. I am not talking about those who develop really complex EE applications all the time, but about developers who download the Application Server and just try out a few samples, or folks who learn one or two technologies at a time or even folks who work on small projects that use only some of the technologies from the Java EE stack. This group of developers would not like to incur the overhead of startup-time/memory for all the services they would not use.
Hence now, the Sun Java System Application Server does not start all the containers during startup. In fact when you install Application Server and start it afresh, there will be only a handful essential services initialized, namely a local JNDI provider, JMX connector (for administration).
Now, how would a developer configure the application server to use the
That is the best part of the feature. User doesn't need to do anything special to initialize the other services that are not started by default. The user uses the application server as he normally would. As and when a service is used, the Application Server will transparently start it.
Here are some details about the implementation.
Mainly there are 3 "entry points" to the Application Server. The entry points are basic functionality in the Application Server that will be used while accessing a user-facing service in Application Server.
1. JNDI Lookup.
Many services and resources in Application Server are looked up using a JNDI name. Examples?
Looking up an EJB, a JDBC resource, a JMS connection factory...
2. Server Ports.
Whenever you do something with the Application Server, a server port is accessed. It can be when you try to see the index.html of the webserver , or connect to the JMS provider from a standalone application, or it can be when you try to lookup a JDBC resource from server's JNDI provider from a standalone Java application.
3. Application Loader.
During the loading of an application,the application Server will read the deployment descriptor of the application for house keeping operations and initialization of the application.
Whenever a user-request reach any of these entry points,the Application Server will identify the type of incoming request and start all relevent services (or service groups) that are required. For example, if the user is accessing http port and if webserver is not started, then the webserver is started lazily/transparently. Or if user is accessing JMS port and JMS provider is not started, Application Server will start the JMS provider. When an ear file containing a EJB is loaded, and ORB is not yet started, Application Server will start ORB.
If you are interested in this feature, the code is available for you to see at GlassFish FishEye page .
If you like to download the latest MSbuild of glassfish, see the link here
For any questions/comments, please use the comments section below or post them at the GlassFish developer's mailing list firstname.lastname@example.org