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. > >

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. >>> >>> >>> >> >

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. >>>>> >>>>> >>>>> >>>> >>> >> >

Which will be soon, hopefully?

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

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

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

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