Discussions

News: Binod on Lazy Initialization of Application Server Services

  1. Binod has written a blog entry entitled "Lazy Initialization of Application Server Services" to present a sort of FAQ on Sun's use of lazy initialization in Glassfish.
    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).
    Is this capability/functionality in other servers as well? If so, which? Is it done well and wisely, and is such a feature - encountered only during startup - a wise focus of resources?
  2. This doesn't sound too different from Geronimo and JBoss - they both have a core kernel then everything else is pluggable on top.

    James
    LogicBlaze
  3. But do they initialize it on demand, or simply load in a sequence?
  4. The JBoss/Geronimo approach is to allow you to specify up front which services you need. You want to incur the initialization costs during server startup, not in the middle of the first user transaction that requires the service.
  5. The JBoss/Geronimo approach is to allow you to specify up front which services you need. You want to incur the initialization costs during server startup, not in the middle of the first user transaction that requires the service.

    Agreed. Plus at any time you can hot-deply new features/services inside a running server if you wish.

    James
    LogicBlaze
  6. The JBoss/Geronimo approach is to allow you to specify up front which services you need. You want to incur the initialization costs during server startup, not in the middle of the first user transaction that requires the service.
    I would change that to "If possible, you want to incur...".

    In our case, we have currently shitloads of plugins and services being started in our product, and it is causing development time to grow and unnecessary memory usage in production.

    However, what services and plugins to start cannot be determined by an administrator, as it is wholly dependent on what the users actually does. In such cases a pure lazy-load approach is the only option.

    Also, you have to consider the cost of starting a service. My experience is that quite often it is just a matter of instantiating some classes, maybe set up some internal structure, etc., but it's not really *that* heavy, in terms of time. In such cases I would not have a problem with it being started as a result of a user interaction.

    We use Pico for our component management and I have made an extension that lets us add component proxies that can handle lazy initialization of subcontainers and subcomponents. This also allows us to shut down components if they are unused, and in advanced cases redeploy them (not very useful for production though). Quite handy, and simple enough to actually be used. Handling these things is something that can probably be overengineered in absurdum.

    As always, YMMV.
  7. But do they initialize it on demand, or simply load in a sequence?

    Currently, JBoss does it all at startup. However, lazy startup of services is planned (as an option) for JBoss 5. This is part of the new microcontainer effort that Adrian Brock is working on right now.

    I think it's a very useful feature.
  8. This is part of the new microcontainer effort that Adrian Brock is working on right now.I think it's a very useful feature.

    Indeed, though it is only one aspect of the JBoss5 improvements to the deployment state machine and
    supporting services.

    I do see it being more used at development time
    and/or to snapshot a production configuration
    from what actually gets used. Including sizing
    pools, caches, etc. from load tests.

    Binod's version looks very domain specific
    and not very granular?
    Which is ok since he envisions a very specific set of
    service topologies.
    From the commit message:
    "
    Appserver services will not start (only in PE) unless a userapp
    require them. Services are divided into three groups and each one
    of them will be started on demand. The service groups are
    1. EJBServiceGroup [ Main components are ORB, JTS and system apps [MEJB and timer]
    2. WebServiceGroup [Main component is Webcontaier and system apps [ admin and webstart]
    3. ResourcesServiceGroup [MQ]
    "
  9. Focus of on-demand initialization in GlassFish has been the usecases that user will come across. So, that appear more domain driven approach. Going forward, servicegroup can be further divided to smaller groups.

    However, even now, each resource (essentailly connection pool) in GlassFish is also loaded on-demand. That way for most of the practical cases, resource utilization of the server is more or less on-demand.

    - Binod.
  10. 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".

    I don't think that Java EE is considered a "heavyweight" container. EJB container is considered "heavyweight" ! Furthermore lazy instantiation doesn't solve this problem whatsoever. It is quite good that if your application doesn't use EJBs then there is not need for a EJB container to be bootstraped. As a consequence to this, more resources are available to your application instead of being held by EJB container even if you're not using EJBs.

    Marius
  11. Is this needed?[ Go to top ]

    I use fairly modern hardware, so maybe I'm not seeing a problem, that others see.

    My questions are: How much memeory is saved? and How much is shaved from the startup time?

    I have been working a lot with Resin and OC4J. Memory footprint, and startup times don't seem to be an issue to me. Is the memory footprint, and start times of JEE containers a problem for some (or most) people?
  12. Is this needed?[ Go to top ]

    +1.

    For production servers, they are restarted, like, once a year?

    For dev servers, from my experience, open source servers (tomcat, jboxx, resin, geronimo) start pretty fast out of box. Commercial ones like weblogic and websphere are slower, but still not anywhere near being a problem.
  13. Is this needed?[ Go to top ]

    Commercial ones like weblogic and websphere are slower, but still not anywhere near being a problem.
    Really?! Please tell me how to make them start and deploy webapp in 8-10 sec and I will owe you beer
  14. Is this needed?[ Go to top ]

    Commercial ones like weblogic and websphere are slower, but still not anywhere near being a problem.
    Really?! Please tell me how to make them start and deploy webapp in 8-10 sec and I will owe you beer

    Don't know for websphere, but weblogic can start, and deploy a simple webapp, in about 8 secs.
    I can mail you config.xml and start script if needed :-)
    Too bad I'm in switzerland (can't find a good beer here).

    On the other hand, it can take some 110-120 secs to start a server when I deploy
    - 3 startup classes
    - 4 ears with
         * some 300 beans all of the latter with initial-beans-
           in-free-pool > 0 and the beans connecting to a host
           system and
         * a couple of webapps in the ears
         * the whole with more than 100MB of jars
    - a bunch of DB connections (that have to be established)

    As for the original subject: most of the containers only need a few seconds for their own housekeeping.
    For production environments this is obviously not an issue.
    For development environments I doubt it is (in the end all of the containers support re-deploy anyway)