Jaikiran Pai wrote:
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.
I think the dependency on LongRunningTasksThreadPool comes from HAJNDI
bean. all/deploy/cluster/hajndi-jboss-beans.xml references
"LookupPool", which is defined in jboss-service.xml:
<!-- The thread pool service used to control the bootstrap lookups -->
<attribute name="LookupPool">
<inject bean="LongRunningTasksThreadPool"/>
</attribute>
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
>>
>
>