[jboss-dev] Different Boottimes from pruning

Brian Stansberry brian.stansberry at redhat.com
Fri Dec 18 09:47:48 EST 2009


On 12/18/2009 08:23 AM, Howard Gao wrote:
> Now the latest release of JBM connects the two channels in different
> threads.

Excellent! That's nice for users of the 5 series.

> But unfortunately for JBM to be fully started and ready for
> work, we need both channels to finish their connections.
> So with parallel in place, it is the channel who takes longer time to
> connect decide the total connect time. Before that we can't print out
> message like "JBoss Messaging 1.x is started" on to the console (or can we?)
>
> https://jira.jboss.org/jira/browse/JBMESSAGING-1680
>
> Next thing in JBM that affects the start up time is the DB operation,
> esp the first time, it will create a bunch of tables in DB if not exist.
>
> Howard
>
>
>
>
>
> Brian Stansberry wrote:
>> 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
>>>
>>
>>
>>
>
> _______________________________________________
> 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



More information about the jboss-development mailing list