[jboss-dev] Startup time for LongRunningTasksThreadPool in trunk

Copying jboss-dev. This is a simple dependency issue. Within the timings Scott is seeing for the LongRunningTasksThreadPool are the create and start phases of not-yet-installed deployments that depend on it. The JChannelFactory bean in the jgroups-channelfactory.sar is one such. The HAPartition bean depends on that. And it connects a JGroups channel, which uses multicast to discover other available servers. On the first couple servers in a group that discovery takes 2 seconds. Plus there's a bunch of other services that depend on HAPartition and start when it does. For AS 6 I want to make the HAPartition an on-demand service, which will push this cost off onto whoever actually uses it. Parallel deployment will also help, since most of the time HAPartition is starting it's just blocking waiting for a response to its discovery packet. The overall ~3.5 secs Scott's report shows for all this also seems high. There's a fairly expensive JBoss Cache initialization in there that seems to be happening twice; I need to understand why. For understanding DefaultDS, suggest you look at what depends on it in the all config that doesn't in the default config. Most likely the difference in deployment time is simply the time it takes to deploy other stuff. Perhaps JBM??? It would take a lot longer in "all" as in clustered mode it connects 2 JGroups channels with a 2 sec discovery phase for each -- until the AS moves to JBM 2 at which time JBM won't use JGroups. The jgroups-channelfactory.sar itself has no relationship to DefaultDS. -Brian Jaikiran Pai wrote: -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat