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

[Jaikiran Pai]

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