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

[Scott Marlow]

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