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

[Brian Stansberry]

Hmm, good point.

The HAPartition depends on the "ThreadPool" bean, which is deployed in 
the same deployment as LongRunningTasksThreadPool. And the start phase 
of HAPartition is where the bulk of the time is spent. See the entry 
labeled "bean=LongRunningTasksThreadPool, context name=HAPartition, 
method=AbstractController.incrementState, install from:Create to:Start, 
ms." in Scott's report. 3126 ms of the total 3987 to install.

I'm looking now to try to get the exact relationship. HAPartition also 
depends on jboss:service=Naming which depends on 
LongRunningTasksThreadPool. How the JChannelFactory ties in isn't clear 
to me yet.

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


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat