[jboss-dev] Startup time for LongRunningTasksThreadPool in trunk

[Brian Stansberry]

Copying jboss-dev.

This is a simple dependency issue. Within the timings Scott is seeing 
for the LongRunningTasksThreadPool are the create and start phases of 
not-yet-installed deployments that depend on it. The JChannelFactory 
bean in the jgroups-channelfactory.sar is one such. 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