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#...
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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development