[jboss-dev] Different Boottimes from pruning

[Brian Stansberry]

The first post on that thread is from a start of the "all" config. 
There, JBM is starting 2 JGroups channels, each of which, in a single 
node cluster waits 2 seconds to get a response to a multicast discovery 
message. Which will never arrive, since there are no other nodes to 
reply. It goes faster once there are other nodes that reply.

This kind of thing is where parallelization of startup can be very 
beneficial. (You'll note that Bela is a big advocate of 
parallelization.) The HAPartition service also connects a channel and 
blocks 2 seconds, so a total of 6 seconds in the startup of the "all" 
config is spent with the startup thread blocking doing nothing.

Note that JBM is connecting 2 channels. If JBM were going to remain in 
AS trunk this fall I'd have pushed the JBM folks to do those in parallel 
internally to the PostOffice's start() impl. HAPartition does that. But 
HornetQ will soon replace JBM in trunk, and HornetQ doesn't connect 
JGroups channels.

On 12/18/2009 02:25 AM, Kabir Khan wrote:
> Last I looked, messaging was taking quite a long time to start up. I'm not sure of the current status:
>   http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242286#4242286
> On 17 Dec 2009, at 16:11, Andrew Lee Rubinger wrote:
>
>> I've got to shuffle off soon (PTO for holiday travel), but I've
>> committed a test env which should isolate things fairly well.
>>
>> http://community.jboss.org/thread/145963
>>
>> S,
>> ALR
>>
>> On 12/17/2009 10:38 AM, David M. Lloyd wrote:
>>> IIRC this problem has been known since the developer meetings last June (?)
>>> when Jaikiran did all that profiling.  Is anyone working on resolving this
>>> issue?
>>>
>>> - DML
>>>
>>> On 12/17/2009 09:17 AM, Bill Burke wrote:
>>>> Richard, this isn't saying there is something wrong with your design,
>>>> because IMO, there isn't... Its purely an implementation problem of the VDF.
>>>>
>>>> Bill Burke wrote:
>>>>> Ok, i did a profile of nothing in deploy/ and removed the weld and
>>>>> jbossweb deployers:
>>>>>
>>>>> 30% of total boottime was spent in addDeployer() which makes sense since
>>>>> WebServices adds like what?  30 deployers?  That 30% of time is solely
>>>>> in sorting the deployers.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Richard Opalka wrote:
>>>>>> OK Bill.
>>>>>> Let us know your investigation results, please.
>>>>>> I'm staying tuned ...
>>>>>>
>>>>>> Richard
>>>>>>
>>>>>> On 12/17/2009 02:19 PM, Bill Burke wrote:
>>>>>>> Richard, I'm not convinced it is JBWS.  I'll do an actually profile
>>>>>>> today.  Unless I'm missing something, I'm looking at your deployers and
>>>>>>> not seeing much happening in start().
>>>>>>>
>>>>>>> Richard Opalka wrote:
>>>>>>>
>>>>>>>> I created https://jira.jboss.org/jira/browse/JBWS-2873
>>>>>>>>
>>>>>>>> Will dig deeper.
>>>>>>>>
>>>>>>>> Richard
>>>>>>>>
>>>>>>>> On 12/17/2009 02:01 AM, Bill Burke wrote:
>>>>>>>>
>>>>>>>>> Ok, I did some performance analisys without a profiler or knowledge of
>>>>>>>>> the codebase.
>>>>>>>>>
>>>>>>>>> default/ profile: 33s
>>>>>>>>>
>>>>>>>>> Next I removed everything in deploy.  I also had to remove
>>>>>>>>> jbossweb.deployer, weld.deployer to get things to run:
>>>>>>>>>
>>>>>>>>> 2nd profile: 18.65 seconds
>>>>>>>>>
>>>>>>>>> Now, an interesting thing.  I removed jbossws.deployer.
>>>>>>>>>
>>>>>>>>> No jbossws.deployer: 12.22 seconds.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So, wow!  jbossws.deployer is taking 6 seconds to deploy!
>>>>>>>>>
>>>>>>>>> But why?  I took a wild guess and maybe it was classloading, jar
>>>>>>>>> indexing, or scanning because jbossws.deployer is around 3megs and
>>>>>>>>> dwarfs other .deployers in deployers/ directory.  So, I combined the
>>>>>>>>> seam jar with jacorb.  No significant startup time.  This leads me to
>>>>>>>>> believe this isn't a VFS problem.
>>>>>>>>>
>>>>>>>>> So, maybe its jbossws?  Well, I look at the beans created, and they
>>>>>>>>> really aren't doing anything significant.  BUT there is a SHIT LOAD of
>>>>>>>>> beans being deployed.
>>>>>>>>>
>>>>>>>>> This leads me to believe this is something fundamental with MC.
>>>>>>>>>
>>>>>>>>> BUT...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You probably already know this.
>>>>>>>>>
>>>>>>>>> Cheers.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>> --
>> Andrew Lee Rubinger
>> Sr. Software Engineer
>> JBoss by Red Hat
>> http://exitcondition.alrubinger.com
>> http://twitter.com/ALRubinger
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development


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