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: > 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 >

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 >> > >