[jboss-dev] Different Boottimes from pruning
Howard Gao
hgao at redhat.com
Fri Dec 18 12:23:33 EST 2009
Yes you remind me that the way JBM uses to find out the first node in a
cluster is not correct according to JGroup team's advice.
I'll revisit the code and see if any more improvement can be done.
Thanks
Howard
Brian Stansberry wrote:
> On 12/18/2009 08:23 AM, Howard Gao wrote:
>
>> Now the latest release of JBM connects the two channels in different
>> threads. 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.
>>
>
> Thanks for mentioning this discrepancy.
>
> The reason the data channel takes so long is the discovery timeout
> setting in the JGroups protocol stack config for that channel:
>
> <MPING timeout="5000"
>
> The control channel has this:
>
> <PING timeout="2000"
>
> I don't know if there was a reason for choosing 5 secs or if it just
> crept in. The other channels in the AS use 2. I doubt that having
> different membership between the control and data channels is what you
> want anyway, so I don't think configuring a longer timeout for the data
> channel does anything helpful. I recommend we change it to <MPING
> timeout="2000"
>
> 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
>>
>
>
>
More information about the jboss-development
mailing list