Binod's Blog

Lazy Initialization of Application Server Services.

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
other services?

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 dev@glassfish.dev.java.net

Comments

• 
  This is really exciting. All of those container services that are available is one of the reasons that JEE is considered a "heavyweight" container, rather than a "lightweight" container. We can quibble on "heavy" vs "light".

  You also hear in the community "I don't need JEE, I can just use Tomcat". At which point the coders immediately limit themselves to the few aspects of the JEE spec that Tomcat covers.

  They take the stripped down Tomcat and proceed to heap on it several of the JEE services that are not there, using the non-JEE frameworks and toolkits available, and then build their application.

  Many did this because they didn't care for the JEE lifecycle and development model, and, obviously, this change you're adding doesn't address that argument at all.

  But I assert today that anyone interested in deploying Tomcat may as well deploy Sun's Appserver, or any of the other free app servers. I suggest that simply because you may not use all of the JEE services available in a container, there's no reason to throw out the baby with the bathwater while limiting yourself to solely the services that a servlet container provide you. As your application expands, you may well be tempted by the JEE features, but don't want to cross that line into a full blown container, or learn and configure the new container since you had to do that with Tomcat, etc.

  But if you make the leap to using the appserver up front, even if you want to by design limit yourself to the Servlet spec, you'll already know the JEE server, how to deploy and manage it, etc. When your app and design DOES want to have some little thing that the JEE server provides for you, it's right there, and easy to access vs porting your application to the new containter.

  The overhead and "heavyweight" nature of the appserver, in most applications, is really very small for services that you do not use already, and most systems can easily "pay" that price for those unused services (typically a bit more memory and some idle monitoring threads).

  But now, with this new feature, there is no price for using the appserver over a servlet container. Now all of those services come with a "pay as you go" feature.

  While some may not care much for that actual model of modern JEE development, I want to try and dispel the idea that JEE servers are overly expensive to use. With the modern, quality, free servers available, there's no economic reason to not choose one over say Tomcat (a valid motivation in the past).

  I hope this new feature makes JEE even more attractive to those who wouldn't consider it before.
  

  Posted by: whartung on September 02, 2005 at 05:41 PM

• Lazy Loading of configurations for performance may be the yin of "Fail Fast's" yang:
  http://www.martinfowler.com/ieeeSoftware/failFast.pdf

  During development, I'd want to have a bad configuration found ASAP, but also don't want to wait too long to test a deployed app.

  Not to say this is a bad solution, but the ideal solution here might be to allow, encourage or force users to pick which features they want. I know... yeah right.

  Yet another trade off.
  

  Posted by: krishuggins on September 03, 2005 at 10:46 PM

• Thanks for the comment, whartung,

  Just want to emphasize that the feature is not part of Java EE platform. This is a product specific feature implemented in Glassfish.
  

  Posted by: binod on September 04, 2005 at 08:39 PM

• Hello krishuggins,
  
  You raised an interesting point about fail-fast. Yes, it is a trade off. However, to a great extend, the issue is taken care in the Application Server. Here are the details.

  1. What issues can comeup during container startup?
  
  One of the main reason why a container initialization can fail is because of the unavailability of the ports configured in the configuration file (In Glassfish's case it is domain.xml). However Sun Java System Application Server starts a socket listener for all ports and hence will handle the port unavailability early enough.
  
  Another reason, why a container initialization can fail is because user screw up the configuration, jar files etc. Now, this may cause unexpected behavior. Then the behavior will be unexpected even when lazy initialization is not used.
  
  2.Would application initialization happen lazily?
  
  No. As soon an application deployment start, the containers required by that application will be initialized and then application will start. That means when a “asadmin deploy” command return, you will know whether the application has been successfully started or not.
  
  Though the initialization of services does not happen at the startup, and though it happens lazily, it happens as soon as application server get to know that user is planning to use a service.

  Posted by: binod on September 04, 2005 at 09:58 PM

• Just want to emphasize that the feature is not part of Java EE platform
  Yes, I realize that, but now perhaps some will use GlassFish rather than simply Tocmat because of the lazy initialization and 'pay as you go' aspects of the new server.

  Posted by: whartung on September 06, 2005 at 09:33 AM

• Hi Binod, krishuggins,
  If we see the Criteria # 3 regarding the entry points, it says that a container/component/service will be started if there is an entry in the deployment descriptor that needs the same. So if there is a defect, that will be shown up in the startup itself. Am I missing a point or other?

  Posted by: hbonline on September 06, 2005 at 10:55 PM

• Yep. So, if there is an app that contains a wrong configuration, it will get an error during deployment itself. That is the earliest it can fail. Isnt that the exected behaviour?

  Posted by: binod on September 06, 2005 at 11:19 PM

• Absolutely. That was the point I was trying to make.

  Posted by: hbonline on September 07, 2005 at 12:38 AM

• How do you compare the performance of this versus more sophisticated and proven frameworks like Spring. Spring also uses the same approach, is xml based and pretty organized. Infact Spring is making a good substitute for J2EE since its light weight.

  Posted by: anilgrover on September 07, 2005 at 08:10 AM

• It seems like people are intrested in comparing a car with a gearbox !

  Posted by: hbonline on September 07, 2005 at 11:18 PM

• That's great. A Sun appserver nearly as light as Tomcat. With embedded derby that's an awesome combination.

  Posted by: mparaz on September 08, 2005 at 04:00 AM

• If you are interested, see TSS discussion on this topic

  Posted by: binod on September 09, 2005 at 07:09 AM

• What about Web Services? Are Web Services lazily loaded as well? This poses major problems to Applications that can be reached using other protocols.

  For example, in my project, I have an Application that uses Web Services and CORBA. Other CORBA applications can not talk to this application UNTIL a Web Service application talks to this application.

  Not having a choice to lazily load the web service or load at container initialization of web services seems very limiting and forces developers to perform hacks (such as having a servlet load at startup and call the web service) to circumvent the issue.

  Is this what Project Glassfish does?

  Posted by: ronak2121 on August 24, 2006 at 03:20 PM

This work is licensed under a Creative Commons License.