[jboss-dev] Re: Startup time for LongRunningTasksThreadPool in trunk

Brian Stansberry wrote: > The JChannelFactory bean in the jgroups-channelfactory.sar is one such. Brian, is this dependency on LongRunningTasksThreadPool for JChannelFactory added programatically? The jgroups-channelfactory-jboss-beans.xml does not show any dependency on the LongRunningTasksThreadPool MC bean. regards. -Jaikiran > 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: >> Scott Marlow wrote: >>> >>> >>> It looks like the 3.5 seconds to boot the LongRunningTasksThreadPool >>> is attributed to jgroups-channelfactory.sar (brought in for JBoss >>> Cache + DistributedState). >> That's strange, because these two seem to be independent deployments >> (no dependency either). So while installing >> LongRunningTasksThreadPool we ideally shouldn't have seen any other >> deployments affecting its timings. But this does seem to be the >> likely cause and it explains why the LongRunningTasksThreadPool boots >> faster (as reported by the deployer timings) in the "default" profile >> where the jgroups-channelfactory.sar is not present. >> >> There are other deployments (like the DefaultDS in hsqldb-ds.xml) >> which take significantly large time compared to the time in the >> "default" profile. Probably those too are affected by the >> jgroups-channelfactory.sar? >> >> -Jaikiran >> > >