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
>