I thought you'd always pass in the test's bare name (without the package), e.g.: mvn clean install -Dtest=ParseAndMarshalModelsTestCase Cheers, David On 06/12/2011 12:42, Kabir Khan wrote: > It seems the latest commit to the testsuite now breaks the ability to do > cd testsuite/integration/smoke > mvn clean install -Dtest=org.jboss.as.test.smoke.embedded.parse.ParseAndMarshalModelsTestCase > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

mvn clean install -Dtest=org.jboss.as.test.smoke.embedded.parse.ParseAndMarshalModelsTestCase is how I used to run it too. Thanks for fixing it. -Jaikiran On Tuesday 06 December 2011 07:31 PM, Kabir Khan wrote: > Not sure, it used to be possible to do it the way I put in. > > I've put it back to what we used to have by commenting out the onlyOneSurefireExecution profiles from smoke and basic. It will try to run the test for each execution, i.e. full and web. However full is done first, so tests should pass there. The web execution might fail if the test targets the full profile. > > On 6 Dec 2011, at 13:03, David Bosschaert wrote: > >> I thought you'd always pass in the test's bare name (without the >> package), e.g.: >> >> mvn clean install -Dtest=ParseAndMarshalModelsTestCase >> >> >> Cheers, >> >> David >> >> On 06/12/2011 12:42, Kabir Khan wrote: >>> It seems the latest commit to the testsuite now breaks the ability to do >>> cd testsuite/integration/smoke >>> mvn clean install -Dtest=org.jboss.as.test.smoke.embedded.parse.ParseAndMarshalModelsTestCase >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

If you set org.jboss.server.bootstrap.maxThreads you disable the boot time logic that tries to parallelize running all the operations that load extensions and install subsystems subsystem. Why? Because that parallelization spawns quite a number of threads, and the original intent of org.jboss.server.bootstrap.maxThreads was to control thread counts. And there's been no time to reconcile the two. On 12/9/11 11:39 AM, Dimitris Andreadis wrote: > I was experimenting a bit with the MSC threadpool size > (org.jboss.server.bootstrap.maxThreads) vs boot time and I've put the results here: > > http://community.jboss.org/wiki/ModularServiceContainer-OptimalThreadpool... > > On my quad-core/dual-threaded machine with 8 reported processors, the default pool size is > 16 (processors x 2). In most cases this looks like an overkill to me, i.e. you can get > pretty much the same or better results with a thread pool of 4, or even 2. > > Another conclusion seems to be that not too much stuff gets parallelized under the hood? > Even with 1 thread the default config boots pretty much in the same time, while some benefit > kicks in as soon as you have some form of I/O in the full and ha configs. But even then, > with a thread pool of 2 you achieve most of this gain. > > Do I miss something? Do you see different results? > > Just try a single threaded boot: > standalone.bat -Dorg.jboss.server.bootstrap.maxThreads=1 > > I am using the latest 7.1.0.CR1-SNAPSHOT > > /D > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 12/9/11 3:03 PM, Dimitris Andreadis wrote: > Brian, I am not sure I understand, especially the reconciliation bit. > > You are saying that whoever is producing the task list to feed to the pool is not breaking > those tasks into pieces that can be parallelized? > In 7.0 the operations that build up the in-memory configuration model, load extensions, call service constructors and and tell the MSC to install the services are all done on a single thread, called the "boot thread". MSC uses a thread pool to parallelize wiring together and starting the services, but a lot of work is done on that single thread. This single threaded boot behavior is the way AS 7.0 always worked. For 7.1 I added logic to execute a lot of that "boot thread" work in parallel. But that logic is disabled if you set org.jboss.server.bootstrap.maxThreads.

> In any case, we seem to have many threads sitting there idle. > > I suppose, I need to look at the code in more detail. > > On 09/12/2011 22:02, Brian Stansberry wrote: >> If you set org.jboss.server.bootstrap.maxThreads you disable the boot >> time logic that tries to parallelize running all the operations that >> load extensions and install subsystems subsystem. >> >> Why? Because that parallelization spawns quite a number of threads, and >> the original intent of org.jboss.server.bootstrap.maxThreads was to >> control thread counts. And there's been no time to reconcile the two. >> >> On 12/9/11 11:39 AM, Dimitris Andreadis wrote: >>> I was experimenting a bit with the MSC threadpool size >>> (org.jboss.server.bootstrap.maxThreads) vs boot time and I've put the results here: >>> >>> http://community.jboss.org/wiki/ModularServiceContainer-OptimalThreadpool... >>> >>> On my quad-core/dual-threaded machine with 8 reported processors, the default pool size is >>> 16 (processors x 2). In most cases this looks like an overkill to me, i.e. you can get >>> pretty much the same or better results with a thread pool of 4, or even 2. >>> >>> Another conclusion seems to be that not too much stuff gets parallelized under the hood? >>> Even with 1 thread the default config boots pretty much in the same time, while some benefit >>> kicks in as soon as you have some form of I/O in the full and ha configs. But even then, >>> with a thread pool of 2 you achieve most of this gain. >>> >>> Do I miss something? Do you see different results? >>> >>> Just try a single threaded boot: >>> standalone.bat -Dorg.jboss.server.bootstrap.maxThreads=1 >>> >>> I am using the latest 7.1.0.CR1-SNAPSHOT >>> >>> /D >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>

On 12/9/11 3:49 PM, Carlo de Wolf wrote: > On 12/09/2011 10:34 PM, Brian Stansberry wrote: >> On 12/9/11 3:03 PM, Dimitris Andreadis wrote: >>> Brian, I am not sure I understand, especially the reconciliation bit. >>> >>> You are saying that whoever is producing the task list to feed to the pool is not breaking >>> those tasks into pieces that can be parallelized? >>> >> In 7.0 the operations that build up the in-memory configuration model, >> load extensions, call service constructors and and tell the MSC to >> install the services are all done on a single thread, called the "boot >> thread". MSC uses a thread pool to parallelize wiring together and >> starting the services, but a lot of work is done on that single thread. >> >> This single threaded boot behavior is the way AS 7.0 always worked. For >> 7.1 I added logic to execute a lot of that "boot thread" work in >> parallel. But that logic is disabled if you set >> org.jboss.server.bootstrap.maxThreads. > > Still the Controller Boot Thread is busy reading away the xml while > other threads are waiting > for something to do. > > Which is why I wrote https://github.com/wolfc/jboss-as/tree/stream-ops a > long time ago. > But this ran into stability issues with the ServiceVerificationHandler. > > Brian and I already asserted that doing streaming ops now is a pain the ... > If we really want this we can take another look, but I don't see why. > It's already #@*%ing fast. > If you don't execute the boot ops as a unit you get the ServiceVerificationHandler issues, since the SVH sees each individual op registering services and barfs it is finds unfilled dependencies. A streaming solution has to support executing the ops as a unit. The current boot divides the operations into 2 big chunks each of which is executed like a composite operation, i.e. as a unit. The chunks are everything up to the last "extension add" and everything after that. (There is parllelization within the execution of those 2 chunks, but that's a detail.) This should allow streaming to work -- parsing thread streams ops, polling thread builds the first set of ops into a chunk and sends it off to an execution thread, and while those execute the polling thread builds the second chunk. Whether that will save much time on a typical developer machine, I don't know. My SWAG is 50ms. So, something to look at after 7.1 is done. I'm sure at some point we'll go off on another boot time reduction binge -- it's fun work! Note that in 7.0 a lot of the parsing time was actually classloading time -- as each<extension> element is parsed, its module is loaded, the Extension service is loaded via ServiceLoader and the Extension is asked to register its parser. That is all done in parallel now -- unless org.jboss.server.bootstrap.maxThreads is set. > Carlo > >> >>> In any case, we seem to have many threads sitting there idle. >>> >>> I suppose, I need to look at the code in more detail. >>> >>> On 09/12/2011 22:02, Brian Stansberry wrote: >>>> If you set org.jboss.server.bootstrap.maxThreads you disable the boot >>>> time logic that tries to parallelize running all the operations that >>>> load extensions and install subsystems subsystem. >>>> >>>> Why? Because that parallelization spawns quite a number of threads, and >>>> the original intent of org.jboss.server.bootstrap.maxThreads was to >>>> control thread counts. And there's been no time to reconcile the two. >>>> >>>> On 12/9/11 11:39 AM, Dimitris Andreadis wrote: >>>>> I was experimenting a bit with the MSC threadpool size >>>>> (org.jboss.server.bootstrap.maxThreads) vs boot time and I've put the results here: >>>>> >>>>> http://community.jboss.org/wiki/ModularServiceContainer-OptimalThreadpool... >>>>> >>>>> On my quad-core/dual-threaded machine with 8 reported processors, the default pool size is >>>>> 16 (processors x 2). In most cases this looks like an overkill to me, i.e. you can get >>>>> pretty much the same or better results with a thread pool of 4, or even 2. >>>>> >>>>> Another conclusion seems to be that not too much stuff gets parallelized under the hood? >>>>> Even with 1 thread the default config boots pretty much in the same time, while some benefit >>>>> kicks in as soon as you have some form of I/O in the full and ha configs. But even then, >>>>> with a thread pool of 2 you achieve most of this gain. >>>>> >>>>> Do I miss something? Do you see different results? >>>>> >>>>> Just try a single threaded boot: >>>>> standalone.bat -Dorg.jboss.server.bootstrap.maxThreads=1 >>>>> >>>>> I am using the latest 7.1.0.CR1-SNAPSHOT >>>>> >>>>> /D >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >> > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev