"adrian(a)jboss.org" wrote : | | * Not all services define their dependencies properly. It's only the implicit | sequential order that makes them work correctly | The let's make the default sequential unless we explicitly tag a deployment as asynchronous (as you mention further down). Although I'd prefer it to be the other way round. anonymous wrote : | * The Sun classloading doesn't work very well concurrently. We avoid a number of potential problems by doing a sequential load of most of the key classes during the bootstrap. | What prevents us from loading those key classes up front, and then deploying in parallel ? anonymous wrote : | * The "big ball of mud" unified classloader depends for consistency/predictability on having the classloaders created in order. It is this order that is used to search for global classes. If these were registered concurrently across threads the search order would be unpredicatble across different reboots. | The big ball of mud is controlled by us, right ? So we can change it. The above sounds like a kludge anyway... (Caveat, I'm not a classloader expert... :-)) [quote * The old 4.x MicroKernel has some thread safety issues, e.g. invocations of create/start are done in synchronized blocks which could cause deadlock problems, there are others related to ConcurrentModificationExceptions. This is not an issue with the 5.x Microcontainer. Then the feature is for AS 5 only, and not available in 4.x. anonymous wrote : | * We'd need to find a way for the BarrierService and "Server Started" notification to know when all the startup threads have finished, otherwise | they would be broken. | Yes. One big barrier would probably be enough to sync on for all threads when they're completed, at least in a first impl. This would tell us that startup of JBossAS is 'done'. anonymous wrote : | * Finally, less of a practical issue, but more a generic note. Using mulitple threads for startup will only work if there are multiple cpus/cores. In non SMP environments the bootstrap could be slower with multiple competing threads, although | it may be able to take advantage of times during disk I/O waits | to do some processing on other threads? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131435#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...