Use caching, serialization and snapshots to speedup JBoss AS startup -------------------------------------------------------------------- Key: JBAS-3730 URL: http://jira.jboss.com/jira/browse/JBAS-3730 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public(Everyone can see) Reporter: jarkko Lietolahti When using JBoss AS in development i feel that the startup time of AS is waaayyy too long, it's something between 20 seconds (very trimmed down version, almost ripped off of all the required services) to 1 minute on my 2GHz laptop with 2 gigabytes of memory. So speed up the startup time of standard(aka default with ejb3) JBoss AS. By this i mean speed up the startups especially in development environments. It's ok for the initial startup after clean installation to take more time. But during "clean" startup JBoss AS should use caching, serialization, snapshots and all the available ways to make the next startup lightning fast. By lightning fast i mean 2 to 5 seconds. This can ofcourse happen if nothing has changed in the configuration, which is usually the case during development where the AS has been shutdown for reasons like unrecorable error (like hanging transactions), severe hot code replace error (after which the as environment becomes too unstable to continue function correctly), or some configuration change which cannot be done while the as is "online". From boot.log and system.log i can see that there are places where JBoss AS could "cache"/serialize/etc stuff and on next startup use the information from the "cache". I've been trying to do a graph of JBoss AS startup based on the logs to see where the startup process spends it moments. Maybe it would be possible to "cache" RepositoryClassLoader contents and avoid the cost of scanning default/lib directory for jar libaries which stay unchanged for most of the start-stop cycle (atleast during certain development phases). I also noticed on a dual core machine some of the activity during startup/deployment doesn't scale very well. At these phases total cpu usage is ~48-52 %, which indicates that the activity doesn't get the additional benefit of multi core / cpu environment. Of course, a mechanism to detect a change in the configuration/etc should be build also which would detect a change in configuration and reload the changed information.