> I could also volunteer to work on removing AOP > dependencies that currently exist for some components. With your AOP background, I think you would be a perfect fit to do this. I don't think we actually use any direct AOP proxying. We mostly "abuse" AOP for lifecycle callbacks. e.g. @JMX or @JNDI usage Dunno how much of this is really AOP code beyond the pointcut matching. We talked about changing this (at AS6 meeting) to plain OO, but I guess this could all be optimized with more optimized pointcut matching -- afaik, Flavia already did this (for her MSc), it just never saw the light of day properly.

Brian Stansberry wrote: > Yeah, reducing the cost of AOP would be nice. We use the @DisableAOP > annotation to bypass AOPDependencyBuilder, but I don't see that > annotation used much, probably due to use of @JMX. > > EJB3 MC beans, either programatically or through the -beans.xml, have been using @DisableAOP ever since we noticed the performance issue with AOPDependencyBuilder: http://community.jboss.org/thread/104679#344841 http://community.jboss.org/thread/96950?tstart=0 The performance gains were very noticeable. It was relatively easier to add this @DisableAOP to MC beans in EJB3 because the set of MC bean files were few. But it's going to be a difficult task trying to add this to each and every MC bean, infact i am not sure whether any new *-beans.xml in EJB3 have @DisableAOP set. That's one of the reasons why i thought it would be better do disable the AOPDependencyBuilder by default (after all most of the developers shouldn't even know about this internal detail). -Jaikiran _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

> +1, disable AOP wherever possible. I guess we can go the other way now, disabled by default + make lifecycle completely OO. We should then definitely see good improvement. > And I'd even dare say if you want @JMX, why not just > implement it the old fashion with MBean interfaces? It's simple and fast :-) You got that right, it's simple, probably too simple. ;-) I think one would still like to use the real power of POJO and IoC and just register it to MBeanServer for some simple admin/config. I dare to say I think you need to re-read this article :-) * http://java.dzone.com/articles/a-look-inside-jboss-microconta-0 _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

IMO, we should just remove AOP entirely as our customers probably are not going to use it.

For @JMX just write another deployer and do it regularly. Similarly with lifecycle and other features.

Again, if you want to take this route, I'd be happy to do the work. I am willing to spend the next month on boot performance and AS.

It could maybe even be done as part of the annotation plugins, I'll check after the holidays.

Ales Justin wrote: >> IMO, we should just remove AOP entirely as our customers probably are >> not going to use it. > > This is exactly what will happen - remove AOP - if we disable it by > default and re-write lifecycle handling to plain OO, w/o any costly > pointcut matching. > > The only cost is lookup for potential @AOPEnable on the bean. > While we still keep optional cool feature of creating an AOP proxy for a > bean. > >> For @JMX just write another deployer and do it >> regularly. Similarly with lifecycle and other features. > > Regularly? > If you mean to register an mbean, that is actually not what we/users want. > See my response to Dimitris this morning. > There probably is a way to make AOP irrelevant to boot performance, but you need to consider pluses and minuses nevertheless...Everybody (thousands) of users are effected by boot performance, while only a handful care about @JMX, etc.

> While this could be a deployer feature, I think it's far more complex to > do it than tie it into the bean's lifecycle. > e.g. scan for @JMX, remembering the handle, checking if it's overridden > for an instance, ... while we already have all this implemented in > bean's lifecycle handling, it's just not optimized yet. > > What do you mean by "similarly with lifecycle and other features"? > @JMX, @JNDI, @Password, ... is the lifecycle callback. > All these annotations that trigger AOP. Are they under the jboss namespace? Controlled by us?

You might want to consider meta-annotations and turning @AOPEnabled into one. i.e. @AOPEnabled public @interface JMX {...} You look at the bean's class annotations, then look at those annotations for @AOPEnabled. >> Again, if you want to take this route, I'd be happy to do the work. >> I am willing to spend the next month on boot performance and AS. > > Excellent. > So will I and the rest of MC team. Well, I need to know what I could do to help. Is Kabir fine on the AOP stuff? VFS3 seems to be ok? What about removing JMX Kernel Backward Compatibility and upgrading services to MC? I can tackle any of these problems with little guidance I just don't want to be duplicating any work (like with the deployer sorting).

On Thu, 2009-12-31 at 00:14 -0600, Brian Stansberry wrote: > > Would converting mbean services help boot time, assuming that most still > need to expose a JMX interface, i.e. @JMX? Don't get me wrong, this is > something we need to do, but if your goal is to help boot perf I'm not > sure how much it will help. > > The JIRA for the boottime improvements we discussed in July is > https://jira.jboss.org/jira/browse/JBAS-7329. What are we doing on > limiting the scanning of our own classes? I see a number of deployments > without a jboss-scanning.xml. Brian, JBAS-7030 represents that work and is mostly complete (subtask JBAS-7035 is still open).

If you can, please review the changes associated with JBAS-7030 and give me your feedback. For what we did in June, I enabled the AnnotationEnvironment trace logging and kept adding jboss-scanning.xml until the AE boot time annotation scanning was eliminated. As best as I can tell, JBAS-7035 was ignored up until now. This took about 2 seconds off the AS boot. Before: AS booted in 35s:304ms on my machine After: AS booted in 33s:324ms on my machine We should enable the AE trace logging again and see which deployments are now scanning for annotations.

Are there any deployments that need the AE annotation scanning to be enabled?

> > Alexey, could you use any help on XB optimization? > _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

> True, but we use @JMX all over the place. I expect trying to get rid of > it and having all our POJO services register themselves in JMX will end > up sucking in most of the AS team, which will be a significant > distraction from EE 6 work. Personally I think we should explore further > whether this can be optimized before going down that path. > This is something I wouldn't mind doing if Kabir finds that AOP can't be optimized.

Its all AOP,

Classloading (package names),

and the 100k iterations on resolveContexts() I have some pretty good ideas on how to fix resolveContexts() but really wanted to see the AOP/CL changes in there before I look at it.

I would also love to finish my fast-jaxb code generator, but IIRC, it won't shave off more than a second or two.

On 01/04/2010 07:18 AM, Ales Justin wrote: >> Its all AOP, > This one is taken care by Kabir. > >> Classloading (package names), > Perhaps Bill you could have a go at this? > > Basically the solution is trivial, but it's an integration pita. > What we need is an explicit packages export; aka jboss-classloading.xml > with capabilities. Why packages? Why not export/import by module? Also, the jboss-classloading.xml is only a part of a performant solution. Before we consider going to a fully modularized design, we also need to consider a way to implement an O(1) module loading system, so that modules are only loaded on-demand and any module which is not used is never loaded. Otherwise, we'll never be able to scale a "modularized" AS.

Just did some profiling of determineAllPackages in a simple isolated test with jacorb.jar (4.58M) Test took 747ms. 51% was within initEntries (ZipEntryContext) (VFS 2.2.0Alpha1) 11.3% was in VFS.getVFS() 7.8% was in VFS.getRoot() 9% of time was used in determineAllPackages. The rest was just org.jboss.test initialization. So, it may not be determineAllPackages itself, but the initialization of the VFS. Beyond optimizing VFS, it doesn't make much sense, IMO, to use the VFS at all for jboss system, subsystem, component, jars. They don't need to be scanned for anything as all information/metadata can be pre-initialized and stored within the jar in a config file. Bill Burke wrote: > > David M. Lloyd wrote: >> On 01/04/2010 07:18 AM, Ales Justin wrote: >>>> Its all AOP, >>> This one is taken care by Kabir. >>> >>>> Classloading (package names), >>> Perhaps Bill you could have a go at this? >>> >>> Basically the solution is trivial, but it's an integration pita. >>> What we need is an explicit packages export; aka jboss-classloading.xml >>> with capabilities. >> Why packages? Why not export/import by module? Also, the >> jboss-classloading.xml is only a part of a performant solution. Before we >> consider going to a fully modularized design, we also need to consider a >> way to implement an O(1) module loading system, so that modules are only >> loaded on-demand and any module which is not used is never loaded. >> Otherwise, we'll never be able to scale a "modularized" AS. >> > > I think these on-demand and modularization features should be put on > hold until you get a modern app-server that is consumable by developers. > I assure you that boot speed and usability (embedability/unit testing) > are 99% more important to developers than on-demand/modularization. > > I know we can get development-mode AS booting in < 5 secs (web, ejb, tx > jca, jms, ws, rs). > > Bill > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

> Its all AOP, This one is taken care by Kabir. > Classloading (package names), Perhaps Bill you could have a go at this? Basically the solution is trivial, but it's an integration pita. What we need is an explicit packages export; aka jboss-classloading.xml with capabilities. This is already on our TAG todo list -- precise API exposure, OSGi like. Perhaps for initial fix, we could add a simple ant/mvn/build-magic task that would generate an exposure of all packages via capabilities? (what we actually do with that PackagesVisitor)

> and the 100k iterations on resolveContexts() I have some pretty good ideas on how to fix > resolveContexts() but really wanted to see the AOP/CL changes in there > before I look at it. We need to re-work how we do contexts resolve anyway (more custom CL/OSGi, beans, ... resolving). I know there are some tasks wrt this re-write assigned to Adrian. Hence I would leave it off for a while. But if Adrian is a no-show, I would be happy to hear your ideas. (actually, post them to our MC forum anyway) > I would also love to finish my fast-jaxb code > generator, but IIRC, it won't shave off more than a second or two. How does this work with our XB?

> Not understanding why you need this precompiled indexing. Do other OSGi > containers take so freakin long to boot and load jars? Per OSGi you need to explicitly list everything in manifest.mf. Hence no scanning + they immediately know where the class can come from. Not like us, where we have a flat default domain, and we need to check all available resources for matching resource.

> Instead of a jboss-classloading.xml, why not reading the manifest? Or > is somebody working on that? > There's already a osgi maven bundle plugin: http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html Why not use that to generate exported packages? Just tried it out. Pretty cool.

Am 05.01.2010 um 16:08 schrieb Ales Justin: >> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html > This is one of them. SS's Bundlor is another. Please don't make that mandatory. People hated it when they had to pre-/postprocess their java classes when developing stuff for Websphere. JBoss was the clear winner with its "just drop in" deployment. And there are even people that say that this is too cumbersome and it should be enough to replace some bytecode on a redeploy of a slightly changed app.

Please don't make that mandatory.

People hated it when they had to pre-/postprocess their java classes when developing stuff for Websphere. JBoss was the clear winner with its "just drop in" deployment.

And there are even people that say that this is too cumbersome and it should be enough to replace some bytecode on a redeploy of a slightly changed app.

> We've always had a flat domain. JBoss AS 4.x boots in 10 seconds. Sure. But how much smaller is 4.x?

Plus resource lookup doesn't run on top of VFS ...

> Instead of a jboss-classloading.xml, why not reading the manifest? Or > is somebody working on that? This is something we're definitely planning. I once discussed it with Scott what we should support. Afair, we agreed on supporting both. But as you can see from SS+OSGi_repo story, this is not as trivial as it looks. Once we have this fully in place, DML's modularization, etc, we should make sure we can re-use stuff from SS's repo.

On 01/05/2010 09:24 AM, Bill Burke wrote: >>> Instead of a jboss-classloading.xml, why not reading the manifest? Or >>> is somebody working on that? >> This is something we're definitely planning. >> I once discussed it with Scott what we should support. >> Afair, we agreed on supporting both. >> But as you can see from SS+OSGi_repo story, this is not as trivial as it >> looks. >> >> Once we have this fully in place, DML's modularization, etc, >> we should make sure we can re-use stuff from SS's repo. > > There's already a osgi maven bundle plugin. Why not use it? > > http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html > > Why not use that to generate exported packages? Just tried it out. > Pretty cool. > Looks like that can handle exporting all packages via a simple wildcard.

> The question is though, does the VFS get bypassed if this is put in? No. > Because scanning for packages isn't slow once the VFS context is > initialized. The time is all within initializing the VFS context for > the jar. > > Or, is VFS still used for every deployed jar because of subdeployments? Yes. The mechanism you're referring to is jboss-structure.xml. * http://www.jboss.org/community/docs/DOC-13178 Even if you use this mechanism, we still need to read into the jar, its META-INF.

Actually, in MC/AS you never use anything else than VFS to navigate/read some stuff in file system.

If you do, it's bad/wrong usage. Since that's why we wrote VFS. ;-)

Brian Stansberry wrote: > On 01/05/2010 09:24 AM, Bill Burke wrote: >>>> Instead of a jboss-classloading.xml, why not reading the manifest? Or >>>> is somebody working on that? >>> This is something we're definitely planning. >>> I once discussed it with Scott what we should support. >>> Afair, we agreed on supporting both. >>> But as you can see from SS+OSGi_repo story, this is not as trivial as it >>> looks. >>> >>> Once we have this fully in place, DML's modularization, etc, >>> we should make sure we can re-use stuff from SS's repo. >> >> There's already a osgi maven bundle plugin. Why not use it? >> >> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html >> >> Why not use that to generate exported packages? Just tried it out. >> Pretty cool. >> > > Looks like that can handle exporting all packages via a simple wildcard. > You don't even need to do that. Just put in the plugin with a regular jar package. <plugins> <plugin> <artifactId>maven-jar-plugin</artifactId> <configuration> <archive> <manifestFile> ${project.build.outputDirectory}/META-INF/MANIFEST.MF </manifestFile> </archive> </configuration> </plugin> <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <version>2.0.1</version> <executions> <execution> <id>bundle-manifest</id> <phase>process-classes</phase> <goals> <goal>manifest</goal> </goals> </execution> </executions> </plugin> </plugins> The question is though, does the VFS get bypassed if this is put in? Because scanning for packages isn't slow once the VFS context is initialized. The time is all within initializing the VFS context for the jar.

Or, is VFS still used for every deployed jar because of subdeployments?

How do you tell it to import all?

See my previous email. :-) I'm saying this might be a problem, due to explicit import. Bill Burke wrote: > > Ales Justin wrote: >> How do you tell it to import all? > > See my previous email. You don't need to configure anything. It > scans bytecode and dependencies to create the import list automatically. > > Here's sample output from my resteasy integration: > > Export-Package: org.jboss.resteasy.integration.deployers;uses:="org.jb > oss.metadata.web.jboss,org.jboss.deployers.spi.deployer.helpers,org.j > boss.metadata.web.spec,org.jboss.deployers.structure.spi,org.jboss.de > ployers.spi,org.jboss.resteasy.plugins.server.servlet,org.jboss.metad > ata.javaee.spec,org.jboss.logging,javax.ws.rs.core,org.jboss.metadata > .ejb.jboss";version="6.0.0.SNAPSHOT" > Tool: Bnd-0.0.357 > Bundle-Name: JBoss Application Server Resteasy > Bundle-Vendor: JBoss, a division of Red Hat, Inc. > Bundle-Version: 6.0.0.SNAPSHOT > Bnd-LastModified: 1262702202594 > Bundle-ManifestVersion: 2 > Bundle-License: http://repository.jboss.org/licenses/lgpl-2.1.txt > Bundle-Description: JBoss Application Server (resteasy module) > Import-Package: javax.ws.rs.core,org.jboss.deployers.spi,org.jboss.dep > loyers.spi.deployer.helpers,org.jboss.deployers.structure.spi,org.jbo > ss.logging,org.jboss.metadata.ejb.jboss,org.jboss.metadata.javaee.spe > c,org.jboss.metadata.web.jboss,org.jboss.metadata.web.spec,org.jboss. > resteasy.integration.deployers;version="6.0",org.jboss.resteasy.plugi > ns.server.servlet > >

Ales Justin wrote: > Perhaps this can be solved by custom (+ temp) deployer, > which would create capabilities from those exports, > but would just say import-all for imports. > No shit shirlock...Especially when thats what is being done now. Again, optimizing this algorithm doesn't matter if jars/directories are being browsed.

David M. Lloyd wrote: > On 01/05/2010 10:40 AM, Bill Burke wrote: >> >> Ales Justin wrote: >>> Perhaps this can be solved by custom (+ temp) deployer, >>> which would create capabilities from those exports, >>> but would just say import-all for imports. >>> >> No shit shirlock...Especially when thats what is being done now. >> >> Again, optimizing this algorithm doesn't matter if jars/directories are >> being browsed. > > What do you mean by "browsed"? If you're going to access any file in a > JAR, you need to scan the (unordered) ZIP directory anyway. Better to do > it one time and cache it so files can be looked up on an O(1) basis. And > once you've done that, why not use that data for other purposes? > A simple test of using ZipInputStream vs. URLClassLoader to find a resource within jacorb.jar. ZipInputStream: 256ms. URLClassLoader: 5ms. URLClasLoader is obviously using some other mechanism to find things.

Anyway this has all been covered, benchmarked, and fixed by VFS3.

On 01/05/2010 12:27 PM, Bill Burke wrote: > > David M. Lloyd wrote: >> Anyway this has all been covered, benchmarked, and fixed by VFS3. >> > Well....not really. > > 446ms now for the PackageTest. > > 65% is still VFS initialization. Using VFS3? If so, can you post details?

I have been running the tests through JProfiler. Not sure if I just have not optimized the profilers settings, but I am getting numbers all over the board, and some are well over double the time of a JUnit execution. The non-profiler time to run the test seems to be<300ms. With the profiler enable, I can see ~30% of the total time is in the VFS.mountZip call. With>10% of the total test time taken up by the 5,085 calls to org.jboss.vfs.util.PathTokenizer.getTokens. The org.jboss.classloading.plugins.vfs.PackageVisitor.determineAllPackages call is taking ~35% of the total test time to run. With ~14% of the total test time in VirutalFile.isDirectory. Maybe there is room for more caching of this isDirectory like calls. There may be a problem with caching the info as the actual file system can change for a given VirutalFile, and the cached information is not guaranteed to remain accurate. John On Jan 5, 2010, at 1:42 PM, Bill Burke wrote: > > > David M. Lloyd wrote: >> On 01/05/2010 12:27 PM, Bill Burke wrote: >>> >>> David M. Lloyd wrote: >>>> Anyway this has all been covered, benchmarked, and fixed by VFS3. >>>> >>> Well....not really. >>> >>> 446ms now for the PackageTest. >>> >>> 65% is still VFS initialization. >> Using VFS3? If so, can you post details? > > Gonna help John Bailey get up to running JProfiler. That cool? > > Preliminary, it looks like a lot of things aren't getting cached (isDirectory, lastModified, isFile, children, etc..). This results in a lot of hash lookups. Looks like they aren't getting cached because of mounting?? Not sure. > > But, I found a problem with my initialization code (see below). It was trying to mount children. I commented out that part and it ran in 251ms. 40% in VFS init if profile CPU time, 60% in actual time. Sometimes jprofiler is weird. > > > > public List<Closeable> recursiveMount(VirtualFile file) throws IOException > { > ArrayList<Closeable> mounts = new ArrayList<Closeable>(); > > if (!file.isDirectory()&& file.getName().matches("^.*\\.([EeWwJj][Aa][Rr]|[Zz][Ii][Pp])$")) > mounts.add(VFS.mountZip(file, file, provider)); > > /****** Doubled speedup when this was commented out!!!!!!!!!!!! > if (file.isDirectory()) > for (VirtualFile child : file.getChildren()) > mounts.addAll(recursiveMount(child)); > */ > > > return mounts; > } > > private TempFileProvider provider; > > protected void setUp() throws Exception > { > super.setUp(); > > provider = TempFileProvider.create("test", new ScheduledThreadPoolExecutor(2)); > } > > protected void tearDown() throws Exception > { > provider.close(); > } > > > > > > > Bill > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com -- John Bailey JBoss by Red Hat -- _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Caching behavior depends on the filesystem. For zip mounts, "isDirectory" and "lastModified" don't even hit the filesystem (in most cases). Don't take JProfiler data as real-world timing; it's useful to find slow spots, sometimes, but it's not an accurate reflection of what the real speed of the thing is. For real filesystem stuff, you CAN NOT EVER do any form of caching of file metainformation because the backing data is not owned by VFS, and thus can change without any sort of notice.

Try the test again with a "warmed up" JVM and no profiler agent installed and you'll probably see a different story.

That's fine BUT a general-purpose caching system will just fuck things up again.

If you know the info won't change, then don't keep asking for it.

There are many different ways in which VFS is used - mounting a library, for example, can be done with a plain zip mount (in other words, everything is in RAM), whereas mounting a hot deployment must first copy the JAR before mounting to avoid locking issues on windows and the "disappearing classes" problem which occurs when you delete the JAR out from under the classloader before the classloader is done with it. Mounting an exploded hot deployment must be done with a more complex copy operation so that changes to dynamic content can be propagated using different rules based on the content (e.g. HTML files should be copied immediately, but the semantics of changing class files is less clear). What can we cache here?

The "ownership" semantics of static files are not clearly defined either, and can depend on what is being mounted and why. I suspect you'll find that there are very few (if any) cases where the filesystem is being hit for information such as "isDirectory" or "lastModified" information outside of hot deployment, which is the case where it can't be cached anyway.

> As I stated early, define a parallel non-cache api that invalidates the > cache on diffs for sensitive operations (like hot-deployment). Sure, if you like bugs and broken behavior. Correctness first, speed second.

This is a complex problem that you cannot paint with a broad brush. You must look at each use case separately before you can say stuff like "we need caching".

On 01/05/2010 04:39 PM, Bill Burke wrote: > David M. Lloyd wrote: >> That's fine BUT a general-purpose caching system will just fuck things up >> again. > With 3.5 years of development you're telling me that our testsuite isn't > good enough to pick up errors introduced by a "general-purpose caching > system" or other optimizations? Yup. The test suite has historically had a very difficult time locating problems which have cropped up in the VFS2 implementation. I guarantee that applying a general solution without understanding each use case will result in crappy code and time-bomb style errors. You can't produce bug-free code just by writing regression tests. >> If you know the info won't change, then don't keep asking for it. > Easier said than done. > > Take for instance VirtulFile.visit(). Any visitor that is run calls > isDirectory(). For each isDirectory() there is at least one > ConcurrentHashMap lookup to find the mount, then to delegate to the > FileSystem interface which itself does hash lookups. Can't be avoided. The topology of mounts may change at any time, which means that one call to isDirectory() might give a different answer than the next for the same file.

How can this possibly be cached when things can be mounted and unmounted at will, by threads other than your own? A VirtualFile is just a symbolic name after all - it does not and can not represent any kind of link into the physical filesystem itself since such a link cannot exist with anything resembling consistent semantics.

It might be worthwhile to explore using some type of COW HashMap setup instead of CHM, since there are relatively few mounts compared to lookups. In any case, O(1) + O(1) = O(1) so algorithmically it's sound. It's just a question of optimization at this stage, if there are any which can be done without breaking the API contract. > Then, visit() continues with calling getChildren() if the file is a > directory. getChildren() recreates a totally brand new VirtualFile > list, by, yes, doing N more hash lookups for each child entry. You're talking about the creation of a list of objects which have three reference fields and one integer field. It's cheap. I already benchmarked the piss out of it, and I'm sure it's not the source of any significant performance issue unless you're doing something crazy.

That's rather disingenuous. VFS failed to get correctness right after 3-4 years, hence it has been rewritten with correctness as the primary goal.

If you want the feature, you pay the price. The requirements are always open for debate, I suppose.

Bill Burke wrote: > For example I just optimized VirtualFile.isDirectory(), isFile(), and > getMount() to cache (and invalidate the cache on a mount). In addition, > I modified VirtualFile.getChildren() to have the FileSystem create the > list of VirtualFiles. Doing so, allowed me to pre-initialize the > isDirectory cache of the VirtualFile. I just got a 12% improvement > (30ms). This improvement was entirely within determinePackageNames, but > still. 30ms * 3 (15 meg of jars) * 2 (Packages + Subdeploy scans) == > 200ms less of App Server boot time. Not much, but its a start. > Eh, I guess its all just splitting hairs. VFS3 is already a huge improvement over VFS2. I guess I'll wait and see what the bottleneck is in AS after AOP, VFS3, and deployer sorting is integrated with AS6 trunk. Sorry for all the bickering. VFS3 looks great. Any ETA on VFS3 being done and integrated with AS 6?

I have been running the tests through JProfiler. Not sure if I just have not optimized the profilers settings, but I am getting numbers all over the board, and some are well over double the time of a JUnit execution. The non-profiler time to run the test seems to be <300ms. With the profiler enable, I can see ~30% of the total time is in the VFS.mountZip call. With >10% of the total test time taken up by the 5,085 calls to org.jboss.vfs.util.PathTokenizer.getTokens. The org.jboss.classloading.plugins.vfs.PackageVisitor.determineAllPackages call is taking ~35% of the total test time to run. With ~14% of the total test time in VirutalFile.isDirectory.

Maybe there is room for more caching of this isDirectory like calls. There may be a problem with caching the info as the actual file system can change for a given VirutalFile, and the cached information is not guaranteed to remain accurate.

The recursive mounting is really for Zip files nested within Zip files. So in this case there is no need. Here is the code I have been testing: --- public class PackageVisitorTestCase extends BaseTestCase { public PackageVisitorTestCase(String s) { super(s); } public void testPackageVisitor() throws Exception { Thread.sleep(1000); URL url = Thread.currentThread().getContextClassLoader().getResource("jacorb.jar"); TempFileProvider provider = null; Closeable handle = null; try { long start = System.currentTimeMillis(); provider = TempFileProvider.create("test", Executors.newScheduledThreadPool(2)); System.out.println("Get Provider: " + (System.currentTimeMillis() - start)); VirtualFile jarFile = VFS.getChild(url); start = System.currentTimeMillis(); handle = VFS.mountZip(jarFile.getPhysicalFile(), jarFile, provider); System.out.println("Mount Zip: " + (System.currentTimeMillis() - start)); VirtualFile[] roots = {jarFile}; start = System.currentTimeMillis(); Set<String> pkgs = PackageVisitor.determineAllPackages(roots, null, ExportAll.ALL, null, null, null); System.out.println("Determine Packages: " + (System.currentTimeMillis() - start)); } finally { VFSUtils.safeClose(handle, provider); } } } On Jan 5, 2010, at 2:24 PM, Bill Burke wrote: > > John Bailey wrote: >> I have been running the tests through JProfiler. Not sure if I just have not optimized the profilers settings, but I am getting numbers all over the board, and some are well over double the time of a JUnit execution. The non-profiler time to run the test seems to be <300ms. >> >> With the profiler enable, I can see ~30% of the total time is in the VFS.mountZip call. With >10% of the total test time taken up by the 5,085 calls to org.jboss.vfs.util.PathTokenizer.getTokens. >> >> The org.jboss.classloading.plugins.vfs.PackageVisitor.determineAllPackages call is taking ~35% of the total test time to run. With ~14% of the total test time in VirutalFile.isDirectory. >> > Ya, JProfiler is all over the place for me too. > > I did currentTimeMillis() timing VFS init took 179/252ms if I don't do > children recursive mount. 420/456ms if I do do recursive child mount. > (Maybe children are getting initialized/cached or something with the > recursive child mount). > > >> Maybe there is room for more caching of this isDirectory like calls. There may be a problem with caching the info as the actual file system can change for a given VirutalFile, and the cached information is not guaranteed to remain accurate. >> > Should be fine to cache for a jar? VirtualFile could ask the FileSystem > if its cacheable or not. > > Or, even better, you could have parallel non-cached getters that could > be used by sensitive logic (like a deploy/ directory scanner). If a > non-cached getter detects a new value, it invalidates the entire cache. > > i.e. > > > Bill > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development -- John Bailey JBoss by Red Hat -- _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

public List<Closeable> recursiveMount(VirtualFile file) throws IOException { ArrayList<Closeable> mounts = new ArrayList<Closeable>(); if (!file.isDirectory()&& file.getName().matches("^.*\\.([EeWwJj][Aa][Rr]|[Zz][Ii][Pp])$")) mounts.add(VFS.mountZip(file, file, provider)); /****** Doubled speedup when this was commented out!!!!!!!!!!!! if (file.isDirectory()) for (VirtualFile child : file.getChildren()) mounts.addAll(recursiveMount(child)); */ return mounts; }

David M. Lloyd wrote: > On 01/05/2010 10:40 AM, Bill Burke wrote: >> Ales Justin wrote: >>> Perhaps this can be solved by custom (+ temp) deployer, >>> which would create capabilities from those exports, >>> but would just say import-all for imports. >>> >> No shit shirlock...Especially when thats what is being done now. >> >> Again, optimizing this algorithm doesn't matter if jars/directories are >> being browsed. > What do you mean by "browsed"? If you're going to access any file in a > JAR, you need to scan the (unordered) ZIP directory anyway. Better to do > it one time and cache it so files can be looked up on an O(1) basis. And > once you've done that, why not use that data for other purposes? > A simple test of using ZipInputStream vs. URLClassLoader to find a resource within jacorb.jar. ZipInputStream: 256ms. URLClassLoader: 5ms. URLClasLoader is obviously using some other mechanism to find things. public void testZipStream() throws Exception { URL url = Thread.currentThread().getContextClassLoader().getResource("jacorb.jar"); ZipInputStream zis = new ZipInputStream(url.openStream()); Map<String, ZipEntry> map = new HashMap<String, ZipEntry>(); ZipEntry entry = null; while ((entry = zis.getNextEntry()) != null) { map.put(entry.getName(), entry); } } public void testClassLoader() throws Exception { URL[] urls = {Thread.currentThread().getContextClassLoader().getResource("jacorb.jar")}; URLClassLoader cl = new URLClassLoader(urls); URL url = cl.getResource("org/jacorb/orb/portableInterceptor/RequestInterceptorIterator.class"); System.out.println(url); } -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

He, hold on here Bill. If you want to measure performance, you have to have huge testing set. Playing with milliseconds doesn't prove anything :( If you measure: ZipInputStream: 256ms. URLClassLoader: 5ms. it doesn't prove anything. ZipInputStream could be affected by thread scheduler and as such not active for some (e.g. 255 ms) time. To prove something is unefficient (e.g. VFS3), you have to create tests that will measure performance in seconds/minutes to measurement don't be affected by thread scheduler or GC. Rio On 01/05/2010 06:18 PM, Bill Burke wrote: > A simple test of using ZipInputStream vs. URLClassLoader to find a > resource within jacorb.jar. > > ZipInputStream: 256ms. > URLClassLoader: 5ms. > > URLClasLoader is obviously using some other mechanism to find things. > -- Richard Opalka ropalka(a)redhat.com JBoss, by Red Hat Office: +420 222 365 200 Mobile: +420 731 186 942 _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Plus, despite what yall might think i'm not a total idiot... ZipInputStream for a 5m file may take 256, may take 286, may take 249. In fact if you expand out most of these micro tests, you still get the same percentage difference. Thats because any GC or thread scheduler will only effect measurements by a few milliseconds in such a small test. Another thing that took off about 15ms +/- was removing inner loop use of Iterator and replacing it with an old school index loop: for ( x : y) replaced with for (int i = 0; i < size; i++) for (x :y) with collections creates an object (the Iterator) plus invoked a few methods (hasNext() and next()). Might seem stupid, but if you're doing this thousands and thousands of times, it adds up. Its too bad the compiler doesn't see this. Anyways... While its not worth looking into saving 30ms here or there right now, it will be worth it after we get the low hanging fruit optimized (AOP, dsorting, VFS2->3 migration). I know we can get boot time under 5 seconds for the default profile. How do I know that? 3 years ago I had embeddable JBoss booting with MC, VDF, JCA, HypersonicDB, Jndi, EJB3, Hibernate, TX, and JMS in under 5 seconds with zero optimizations. My bet is that we can get these components plus JBoss Web for a stripped down dev profile (no profile service, management, hotdeploy, aop, bsh, etc.) in less than 2 seconds with further deep optimizations. In the end we'll have something that is testable, embeddable, and something that totally removes the need for stupid Mock shit. Emmanuel Bernard wrote: > OTOH if the test last minutes, this is not a realistic test either. The bootstrap of AS is the bootstrap of AS, the VM starts from cold that's a fact of life. > > On 8 janv. 2010, at 14:56, Richard Opalka wrote: > >> He, hold on here Bill. >> >> If you want to measure performance, you have to have huge testing set. >> Playing with milliseconds doesn't prove anything :( >> If you measure: >> >> ZipInputStream: 256ms. >> URLClassLoader: 5ms. >> >> it doesn't prove anything. ZipInputStream could be affected by thread >> scheduler and as such not active for some (e.g. 255 ms) time. >> To prove something is unefficient (e.g. VFS3), >> you have to create tests that will measure performance in >> seconds/minutes to measurement don't be affected by thread scheduler or GC. >> >> Rio >> >> On 01/05/2010 06:18 PM, Bill Burke wrote: >>> A simple test of using ZipInputStream vs. URLClassLoader to find a >>> resource within jacorb.jar. >>> >>> ZipInputStream: 256ms. >>> URLClassLoader: 5ms. >>> >>> URLClasLoader is obviously using some other mechanism to find things. >>> >> -- >> >> Richard Opalka >> ropalka(a)redhat.com >> JBoss, by Red Hat >> >> Office: +420 222 365 200 >> Mobile: +420 731 186 942 >> >> _______________________________________________ >> 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 -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

FYI, we're talking about boot, startup performance, not runtime. Robb Greathouse wrote: > Just FYI, we are seeing more interest from Exchanges and Trading applications which are all about latency. So, milliseconds definitely count in these markets. When they are processing millions of transactions a day a few milliseconds per transaction adds up fast. > > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

Ales Justin wrote: >> IMO, we should just remove AOP entirely as our customers probably are >> not going to use it. > > This is exactly what will happen - remove AOP - if we disable it by > default and re-write lifecycle handling to plain OO, w/o any costly > pointcut matching. > > The only cost is lookup for potential @AOPEnable on the bean. > While we still keep optional cool feature of creating an AOP proxy for a > bean. > >> For @JMX just write another deployer and do it >> regularly. Similarly with lifecycle and other features. > > Regularly? > If you mean to register an mbean, that is actually not what we/users want. > See my response to Dimitris this morning. > There probably is a way to make AOP irrelevant to boot performance, but you need to consider pluses and minuses nevertheless...Everybody (thousands) of users are effected by boot performance, while only a handful care about @JMX, etc. > While this could be a deployer feature, I think it's far more complex to > do it than tie it into the bean's lifecycle. > e.g. scan for @JMX, remembering the handle, checking if it's overridden > for an instance, ... while we already have all this implemented in > bean's lifecycle handling, it's just not optimized yet. > > What do you mean by "similarly with lifecycle and other features"? > @JMX, @JNDI, @Password, ... is the lifecycle callback. > All these annotations that trigger AOP. Are they under the jboss namespace? Controlled by us? You might want to consider meta-annotations and turning @AOPEnabled into one. i.e. @AOPEnabled public @interface JMX {...} You look at the bean's class annotations, then look at those annotations for @AOPEnabled. >> Again, if you want to take this route, I'd be happy to do the work. >> I am willing to spend the next month on boot performance and AS. > > Excellent. > So will I and the rest of MC team. Well, I need to know what I could do to help. Is Kabir fine on the AOP stuff? VFS3 seems to be ok? What about removing JMX Kernel Backward Compatibility and upgrading services to MC? I can tackle any of these problems with little guidance I just don't want to be duplicating any work (like with the deployer sorting).

* Writing a maven plugin for embedded (so it works as nicely as jetty's)

> > What do you mean by "similarly with lifecycle and other features"? > @JMX, @JNDI, @Password, ... is the lifecycle callback. > All these annotations that trigger AOP. Are they under the jboss namespace? Controlled by us?

You might want to consider meta-annotations and turning @AOPEnabled into one. i.e. @AOPEnabled public @interface JMX {...} You look at the bean's class annotations, then look at those annotations for @AOPEnabled. >> Again, if you want to take this route, I'd be happy to do the work. >> I am willing to spend the next month on boot performance and AS. > > Excellent. > So will I and the rest of MC team. Well, I need to know what I could do to help. Is Kabir fine on the AOP

stuff? VFS3 seems to be ok? What about removing JMX Kernel Backward Compatibility and upgrading services to MC? I can tackle any of these problems with little guidance I just don't want to be duplicating any work (like with the deployer sorting). -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Kabir Khan wrote: >>> What do you mean by "similarly with lifecycle and other features"? >>> @JMX, @JNDI, @Password, ... is the lifecycle callback. >>> >> All these annotations that trigger AOP. Are they under the jboss >> namespace? Controlled by us? > The @JMX etc. annotations for lifecycle stufff will be handled by the annotation plugins which are invoked as part of the bean's describe phase. Adding/removing them will be easy. So, I don't think metaannotations will be necessary. >> You might want to consider meta-annotations and turning @AOPEnabled into >> one. i.e. >> >> @AOPEnabled >> public @interface JMX {...} >> >> You look at the bean's class annotations, then look at those annotations >> for @AOPEnabled. >> >>>> Again, if you want to take this route, I'd be happy to do the work. >>>> I am willing to spend the next month on boot performance and AS. >>> Excellent. >>> So will I and the rest of MC team. >> Well, I need to know what I could do to help. Is Kabir fine on the AOP > Yes, before finishing for the holidays I got most of the aop-mc-int tests working with weaving not enabled (mvn surefire-report:report -Ptests-no-weave). I am getting failures in the tests with weaving enabled (mvn surefire-report:report -Pant-tests-weave). It is probably something trivial, I'll have a look on Monday. Let me know how it goes. Is this just a matter of plopping the aop-mc-int jar within AS trunk to test?

I think I've got the bypassing proxy stuff working now both with and without weaving. I'm re-running some tests before committing. A summary of what I have done; -AOP proxy creation/checks is disabled by default -@EnableAopProxy on a bean forces it to go through the proxy checks -@DisableAOP is deprecated, but will stil be checked if it is present and the new annotations are not present A few points: -if a bean is not woven but has constructor aspects you want invoked, the bean needs the @EnableAopProxy annotation -If a bean's class is woven it can have aspects, so we will always check the AOP dependencies for that bean. This will only happen if loadtime weaving was turned on (or compile-time weaving was used) AND the bean matches some pointcuts, so it should not be an issue in practice. Once I've tidied up I'll commit to MC trunk, and try putting it into AS trunk before moving on to replacing the mechanism for AOP lifecycle. On 24 Dec 2009, at 12:29, Kabir Khan wrote: > I've made a start on this, but doubt I'll finish it before I finish for Christmas. I am deprecating the @DisableAOP annotation. By default aop proxies will be disabled, but can be enabled with @EnableAopProxy. Lifecycle callbacks will be enabled by default (and I'll come up with a quicker way of determining if they should apply), but can be disabled using the @DisableAopLifecycle annotation. > > One issue that I need to look into is that there are a bunch of tests that run with weaving enabled, so I need to see how they fare with this new setup. Since if they are woven, aspects will apply, and if those aspects have dependencies we need those in AOPDependencyBuilder. > > > On 24 Dec 2009, at 10:47, Ales Justin wrote: > >>> +1, disable AOP wherever possible. >> >> I guess we can go the other way now, disabled by default + make >> lifecycle completely OO. >> We should then definitely see good improvement. >> >>> And I'd even dare say if you want @JMX, why not just >>> implement it the old fashion with MBean interfaces? It's simple and fast :-) >> >> You got that right, it's simple, probably too simple. ;-) >> I think one would still like to use the real power of POJO and IoC and >> just register it to MBeanServer for some simple admin/config. >> >> I dare to say I think you need to re-read this article :-) >> * http://java.dzone.com/articles/a-look-inside-jboss-microconta-0 >> _______________________________________________ >> 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

The work for this has been committed against https://jira.jboss.org/jira/browse/JBKERNEL-75 and https://jira.jboss.org/jira/browse/JBKERNEL-74. I have a few things I need to do before the end of the week, if I have any time I'll try to see what impact this has on AS boot time. On 4 Jan 2010, at 17:28, Kabir Khan wrote: > I tried starting AS with the updated jboss-aop-mc-int.jar, but ran into problems with dependencies. I'll work on the @JMX stuff next, and try to see if I can update all the dependencies locally in AS once I'm done with that if I have some time before our release > > On 4 Jan 2010, at 15:43, Kabir Khan wrote: > >> I think I've got the bypassing proxy stuff working now both with and without weaving. I'm re-running some tests before committing. A summary of what I have done; >> >> -AOP proxy creation/checks is disabled by default >> -@EnableAopProxy on a bean forces it to go through the proxy checks >> -@DisableAOP is deprecated, but will stil be checked if it is present and the new annotations are not present >> >> A few points: >> -if a bean is not woven but has constructor aspects you want invoked, the bean needs the @EnableAopProxy annotation >> -If a bean's class is woven it can have aspects, so we will always check the AOP dependencies for that bean. This will only happen if loadtime weaving was turned on (or compile-time weaving was used) AND the bean matches some pointcuts, so it should not be an issue in practice. >> >> Once I've tidied up I'll commit to MC trunk, and try putting it into AS trunk before moving on to replacing the mechanism for AOP lifecycle. >> >> On 24 Dec 2009, at 12:29, Kabir Khan wrote: >> >>> I've made a start on this, but doubt I'll finish it before I finish for Christmas. I am deprecating the @DisableAOP annotation. By default aop proxies will be disabled, but can be enabled with @EnableAopProxy. Lifecycle callbacks will be enabled by default (and I'll come up with a quicker way of determining if they should apply), but can be disabled using the @DisableAopLifecycle annotation. >>> >>> One issue that I need to look into is that there are a bunch of tests that run with weaving enabled, so I need to see how they fare with this new setup. Since if they are woven, aspects will apply, and if those aspects have dependencies we need those in AOPDependencyBuilder. >>> >>> >>> On 24 Dec 2009, at 10:47, Ales Justin wrote: >>> >>>>> +1, disable AOP wherever possible. >>>> >>>> I guess we can go the other way now, disabled by default + make >>>> lifecycle completely OO. >>>> We should then definitely see good improvement. >>>> >>>>> And I'd even dare say if you want @JMX, why not just >>>>> implement it the old fashion with MBean interfaces? It's simple and fast :-) >>>> >>>> You got that right, it's simple, probably too simple. ;-) >>>> I think one would still like to use the real power of POJO and IoC and >>>> just register it to MBeanServer for some simple admin/config. >>>> >>>> I dare to say I think you need to re-read this article :-) >>>> * http://java.dzone.com/articles/a-look-inside-jboss-microconta-0 >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > 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

I forgot to mention the changes that I did for JBKERNEL-75, i.e. lifecycle: http://community.jboss.org/message/518409#518409 The gist of it is that <lifecycle-configure/> & friends no longer can take an 'expr' attribute (containing a pointcut) and that the 'classes' attribute now must take an annotation. On 5 Jan 2010, at 18:08, Kabir Khan wrote: > The work for this has been committed against https://jira.jboss.org/jira/browse/JBKERNEL-75 and https://jira.jboss.org/jira/browse/JBKERNEL-74. I have a few things I need to do before the end of the week, if I have any time I'll try to see what impact this has on AS boot time. > On 4 Jan 2010, at 17:28, Kabir Khan wrote: > >> I tried starting AS with the updated jboss-aop-mc-int.jar, but ran into problems with dependencies. I'll work on the @JMX stuff next, and try to see if I can update all the dependencies locally in AS once I'm done with that if I have some time before our release >> >> On 4 Jan 2010, at 15:43, Kabir Khan wrote: >> >>> I think I've got the bypassing proxy stuff working now both with and without weaving. I'm re-running some tests before committing. A summary of what I have done; >>> >>> -AOP proxy creation/checks is disabled by default >>> -@EnableAopProxy on a bean forces it to go through the proxy checks >>> -@DisableAOP is deprecated, but will stil be checked if it is present and the new annotations are not present >>> >>> A few points: >>> -if a bean is not woven but has constructor aspects you want invoked, the bean needs the @EnableAopProxy annotation >>> -If a bean's class is woven it can have aspects, so we will always check the AOP dependencies for that bean. This will only happen if loadtime weaving was turned on (or compile-time weaving was used) AND the bean matches some pointcuts, so it should not be an issue in practice. >>> >>> Once I've tidied up I'll commit to MC trunk, and try putting it into AS trunk before moving on to replacing the mechanism for AOP lifecycle. >>> >>> On 24 Dec 2009, at 12:29, Kabir Khan wrote: >>> >>>> I've made a start on this, but doubt I'll finish it before I finish for Christmas. I am deprecating the @DisableAOP annotation. By default aop proxies will be disabled, but can be enabled with @EnableAopProxy. Lifecycle callbacks will be enabled by default (and I'll come up with a quicker way of determining if they should apply), but can be disabled using the @DisableAopLifecycle annotation. >>>> >>>> One issue that I need to look into is that there are a bunch of tests that run with weaving enabled, so I need to see how they fare with this new setup. Since if they are woven, aspects will apply, and if those aspects have dependencies we need those in AOPDependencyBuilder. >>>> >>>> >>>> On 24 Dec 2009, at 10:47, Ales Justin wrote: >>>> >>>>>> +1, disable AOP wherever possible. >>>>> I guess we can go the other way now, disabled by default + make >>>>> lifecycle completely OO. >>>>> We should then definitely see good improvement. >>>>> >>>>>> And I'd even dare say if you want @JMX, why not just >>>>>> implement it the old fashion with MBean interfaces? It's simple and fast :-) >>>>> You got that right, it's simple, probably too simple. ;-) >>>>> I think one would still like to use the real power of POJO and IoC and >>>>> just register it to MBeanServer for some simple admin/config. >>>>> >>>>> I dare to say I think you need to re-read this article :-) >>>>> * http://java.dzone.com/articles/a-look-inside-jboss-microconta-0 >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> 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

i am seeing the same. What I saw pre-merge was that the deployer sorting brought boot time from 30-33 to 26-28. With the changes I'm seing 23-24. 10-20% improvement is about where I thought we'd be with AOP changes. Great job Ales, Kabir and company! Jaikiran Pai wrote: > With the recent upgrade of MC in AS trunk, the "default" config on my > system now boots in around 23 seconds consistently. Before the upgrade > it used to take somewhere around 30 to 33 seconds. > > -Jaikiran > > Kabir Khan wrote: >> I forgot to mention the changes that I did for JBKERNEL-75, i.e. lifecycle: http://community.jboss.org/message/518409#518409 >> >> The gist of it is that <lifecycle-configure/> & friends no longer can take an 'expr' attribute (containing a pointcut) and that the 'classes' attribute now must take an annotation. >> >> On 5 Jan 2010, at 18:08, Kabir Khan wrote: >> >>> The work for this has been committed against https://jira.jboss.org/jira/browse/JBKERNEL-75 and https://jira.jboss.org/jira/browse/JBKERNEL-74. I have a few things I need to do before the end of the week, if I have any time I'll try to see what impact this has on AS boot time. >>> On 4 Jan 2010, at 17:28, Kabir Khan wrote: >>> >>>> I tried starting AS with the updated jboss-aop-mc-int.jar, but ran into problems with dependencies. I'll work on the @JMX stuff next, and try to see if I can update all the dependencies locally in AS once I'm done with that if I have some time before our release >>>> >>>> On 4 Jan 2010, at 15:43, Kabir Khan wrote: >>>> >>>>> I think I've got the bypassing proxy stuff working now both with and without weaving. I'm re-running some tests before committing. A summary of what I have done; >>>>> >>>>> -AOP proxy creation/checks is disabled by default >>>>> -@EnableAopProxy on a bean forces it to go through the proxy checks >>>>> -@DisableAOP is deprecated, but will stil be checked if it is present and the new annotations are not present >>>>> >>>>> A few points: >>>>> -if a bean is not woven but has constructor aspects you want invoked, the bean needs the @EnableAopProxy annotation >>>>> -If a bean's class is woven it can have aspects, so we will always check the AOP dependencies for that bean. This will only happen if loadtime weaving was turned on (or compile-time weaving was used) AND the bean matches some pointcuts, so it should not be an issue in practice. >>>>> >>>>> Once I've tidied up I'll commit to MC trunk, and try putting it into AS trunk before moving on to replacing the mechanism for AOP lifecycle. >>>>> >>>>> On 24 Dec 2009, at 12:29, Kabir Khan wrote: >>>>> >>>>>> I've made a start on this, but doubt I'll finish it before I finish for Christmas. I am deprecating the @DisableAOP annotation. By default aop proxies will be disabled, but can be enabled with @EnableAopProxy. Lifecycle callbacks will be enabled by default (and I'll come up with a quicker way of determining if they should apply), but can be disabled using the @DisableAopLifecycle annotation. >>>>>> >>>>>> One issue that I need to look into is that there are a bunch of tests that run with weaving enabled, so I need to see how they fare with this new setup. Since if they are woven, aspects will apply, and if those aspects have dependencies we need those in AOPDependencyBuilder. >>>>>> >>>>>> >>>>>> On 24 Dec 2009, at 10:47, Ales Justin wrote: >>>>>> >>>>>>>> +1, disable AOP wherever possible. >>>>>>> I guess we can go the other way now, disabled by default + make >>>>>>> lifecycle completely OO. >>>>>>> We should then definitely see good improvement. >>>>>>> >>>>>>>> And I'd even dare say if you want @JMX, why not just >>>>>>>> implement it the old fashion with MBean interfaces? It's simple and fast :-) >>>>>>> You got that right, it's simple, probably too simple. ;-) >>>>>>> I think one would still like to use the real power of POJO and IoC and >>>>>>> just register it to MBeanServer for some simple admin/config. >>>>>>> >>>>>>> I dare to say I think you need to re-read this article :-) >>>>>>> * http://java.dzone.com/articles/a-look-inside-jboss-microconta-0 >>>>>>> _______________________________________________ >>>>>>> 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 >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

I keep getting that too (i started seeing that sometime after 5.1.0.GA was released). I get past it by setting the following 2 properties in JAVA_OPTS: -Djboss.platform.mbeanserver -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl regards, -Jaikiran Ales Justin wrote: > Running JProfiler6 with including JBoss (I removed org.jboss filter) > classes I get the bottom exception. > Any idea how to get past this? > > Is it an issue of JP manipulating with our classes > or does JP change JMX mbeanserver impl? > > ------------------------ > > 14:06:58,531 ERROR [AbstractKernelController] Error installing to > Configured: name=ServiceBindingManager state=Configured: > java.lang.Exception: Error calling callback JMXRegistrationAdvice for > target context ServiceBindingManager > at > org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:91) > at > org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1830) > at > org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1795) > at > org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1008) > at > org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1217) > at > org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1141) > at > org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1048) > at > org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:842) > at > org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:589) > at > org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:180) > at > org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) > at > org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) > at > org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) > at > org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) > at > org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1660) > at > org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1378) > at > org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1399) > at > org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1319) > at > org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:378) > at > org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1856) > at > org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:999) > at > org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1217) > at > org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1141) > at > org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1048) > at > org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:887) > at > org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:602) > at > org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:898) > at > org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:677) > at > org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117) > at > org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70) > at > org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53) > at > org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:403) > at > org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:378) > at > org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1856) > at > org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:999) > at > org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1217) > at > org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1141) > at > org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1048) > at > org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:842) > at > org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:589) > at > org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:308) > at > org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:259) > at > org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:100) > at > org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:860) > at > org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:441) > at java.lang.Thread.run(Thread.java:619) > Caused by: javax.management.InstanceNotFoundException: > JMImplementation:type=MBeanRegistry > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1094) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:833) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) > at > org.jboss.system.microcontainer.jmx.ServiceControllerRegistrationLifecycleCallback.install(ServiceControllerRegistrationLifecycleCallback.java:96) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59) > at > org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:151) > at > org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) > at > org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300) > at > org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:304) > at > org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87) > ... 45 more > _______________________________________________ > 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

I have an older laptop so default for me boots at 29secs. I am sure we can do better, still this is quite an improvement so kudos to everyone! Bill Burke wrote: > i am seeing the same. What I saw pre-merge was that the deployer > sorting brought boot time from 30-33 to 26-28. With the changes I'm > seing 23-24. 10-20% improvement is about where I thought we'd be with > AOP changes. > > Great job Ales, Kabir and company! > > Jaikiran Pai wrote: > >> With the recent upgrade of MC in AS trunk, the "default" config on my >> system now boots in around 23 seconds consistently. Before the upgrade >> it used to take somewhere around 30 to 33 seconds. >> >> -Jaikiran >> >> Kabir Khan wrote: >> >>> I forgot to mention the changes that I did for JBKERNEL-75, i.e. lifecycle: http://community.jboss.org/message/518409#518409 >>> >>> The gist of it is that<lifecycle-configure/> & friends no longer can take an 'expr' attribute (containing a pointcut) and that the 'classes' attribute now must take an annotation. >>> >>> On 5 Jan 2010, at 18:08, Kabir Khan wrote: >>> >>> >>>> The work for this has been committed against https://jira.jboss.org/jira/browse/JBKERNEL-75 and https://jira.jboss.org/jira/browse/JBKERNEL-74. I have a few things I need to do before the end of the week, if I have any time I'll try to see what impact this has on AS boot time. >>>> On 4 Jan 2010, at 17:28, Kabir Khan wrote: >>>> >>>> >>>>> I tried starting AS with the updated jboss-aop-mc-int.jar, but ran into problems with dependencies. I'll work on the @JMX stuff next, and try to see if I can update all the dependencies locally in AS once I'm done with that if I have some time before our release >>>>> >>>>> On 4 Jan 2010, at 15:43, Kabir Khan wrote: >>>>> >>>>> >>>>>> I think I've got the bypassing proxy stuff working now both with and without weaving. I'm re-running some tests before committing. A summary of what I have done; >>>>>> >>>>>> -AOP proxy creation/checks is disabled by default >>>>>> -@EnableAopProxy on a bean forces it to go through the proxy checks >>>>>> -@DisableAOP is deprecated, but will stil be checked if it is present and the new annotations are not present >>>>>> >>>>>> A few points: >>>>>> -if a bean is not woven but has constructor aspects you want invoked, the bean needs the @EnableAopProxy annotation >>>>>> -If a bean's class is woven it can have aspects, so we will always check the AOP dependencies for that bean. This will only happen if loadtime weaving was turned on (or compile-time weaving was used) AND the bean matches some pointcuts, so it should not be an issue in practice. >>>>>> >>>>>> Once I've tidied up I'll commit to MC trunk, and try putting it into AS trunk before moving on to replacing the mechanism for AOP lifecycle. >>>>>> >>>>>> On 24 Dec 2009, at 12:29, Kabir Khan wrote: >>>>>> >>>>>> >>>>>>> I've made a start on this, but doubt I'll finish it before I finish for Christmas. I am deprecating the @DisableAOP annotation. By default aop proxies will be disabled, but can be enabled with @EnableAopProxy. Lifecycle callbacks will be enabled by default (and I'll come up with a quicker way of determining if they should apply), but can be disabled using the @DisableAopLifecycle annotation. >>>>>>> >>>>>>> One issue that I need to look into is that there are a bunch of tests that run with weaving enabled, so I need to see how they fare with this new setup. Since if they are woven, aspects will apply, and if those aspects have dependencies we need those in AOPDependencyBuilder. >>>>>>> >>>>>>> >>>>>>> On 24 Dec 2009, at 10:47, Ales Justin wrote: >>>>>>> >>>>>>> >>>>>>>>> +1, disable AOP wherever possible. >>>>>>>>> >>>>>>>> I guess we can go the other way now, disabled by default + make >>>>>>>> lifecycle completely OO. >>>>>>>> We should then definitely see good improvement. >>>>>>>> >>>>>>>> >>>>>>>>> And I'd even dare say if you want @JMX, why not just >>>>>>>>> implement it the old fashion with MBean interfaces? It's simple and fast :-) >>>>>>>>> >>>>>>>> You got that right, it's simple, probably too simple. ;-) >>>>>>>> I think one would still like to use the real power of POJO and IoC and >>>>>>>> just register it to MBeanServer for some simple admin/config. >>>>>>>> >>>>>>>> I dare to say I think you need to re-read this article :-) >>>>>>>> * http://java.dzone.com/articles/a-look-inside-jboss-microconta-0 >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> _______________________________________________ >> 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

> But it was 40 secs before so KUDOS 2 MC TEAM! Well, a lot of gain was deployers sorting, which is where Bill and you did most of the work. :-)

Would promising beer make up a better incentive? Win 1 pint for every second you can trim off the boot time :-) Ales Justin wrote: > And Carlo. > (to not forget his initial Kahn sorting) > > Ales Justin wrote: > >>> But it was 40 secs before so KUDOS 2 MC TEAM! >>> >> Well, a lot of gain was deployers sorting, >> which is where Bill and you did most of the work. :-) >> >> > _______________________________________________ > 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

Yes, it's nice it boots faster. However there are still some issues, e.g. http://jbossws.jboss.org:8180/hudson/job/NATIVE-CORE-AS-6.0.1-SUN-JDK-6/28/ that have to be addressed/identified :( Rio On 01/13/2010 03:10 PM, Jaikiran Pai wrote: > With the recent upgrade of MC in AS trunk, the "default" config on my > system now boots in around 23 seconds consistently. Before the upgrade > it used to take somewhere around 30 to 33 seconds. > > -Jaikiran > > Kabir Khan wrote: > >> I forgot to mention the changes that I did for JBKERNEL-75, i.e. lifecycle: http://community.jboss.org/message/518409#518409 >> >> The gist of it is that<lifecycle-configure/> & friends no longer can take an 'expr' attribute (containing a pointcut) and that the 'classes' attribute now must take an annotation. >> >> On 5 Jan 2010, at 18:08, Kabir Khan wrote: >> >> >>> The work for this has been committed against https://jira.jboss.org/jira/browse/JBKERNEL-75 and https://jira.jboss.org/jira/browse/JBKERNEL-74. I have a few things I need to do before the end of the week, if I have any time I'll try to see what impact this has on AS boot time. >>> On 4 Jan 2010, at 17:28, Kabir Khan wrote: >>> >>> >>>> I tried starting AS with the updated jboss-aop-mc-int.jar, but ran into problems with dependencies. I'll work on the @JMX stuff next, and try to see if I can update all the dependencies locally in AS once I'm done with that if I have some time before our release >>>> >>>> On 4 Jan 2010, at 15:43, Kabir Khan wrote: >>>> >>>> >>>>> I think I've got the bypassing proxy stuff working now both with and without weaving. I'm re-running some tests before committing. A summary of what I have done; >>>>> >>>>> -AOP proxy creation/checks is disabled by default >>>>> -@EnableAopProxy on a bean forces it to go through the proxy checks >>>>> -@DisableAOP is deprecated, but will stil be checked if it is present and the new annotations are not present >>>>> >>>>> A few points: >>>>> -if a bean is not woven but has constructor aspects you want invoked, the bean needs the @EnableAopProxy annotation >>>>> -If a bean's class is woven it can have aspects, so we will always check the AOP dependencies for that bean. This will only happen if loadtime weaving was turned on (or compile-time weaving was used) AND the bean matches some pointcuts, so it should not be an issue in practice. >>>>> >>>>> Once I've tidied up I'll commit to MC trunk, and try putting it into AS trunk before moving on to replacing the mechanism for AOP lifecycle. >>>>> >>>>> On 24 Dec 2009, at 12:29, Kabir Khan wrote: >>>>> >>>>> >>>>>> I've made a start on this, but doubt I'll finish it before I finish for Christmas. I am deprecating the @DisableAOP annotation. By default aop proxies will be disabled, but can be enabled with @EnableAopProxy. Lifecycle callbacks will be enabled by default (and I'll come up with a quicker way of determining if they should apply), but can be disabled using the @DisableAopLifecycle annotation. >>>>>> >>>>>> One issue that I need to look into is that there are a bunch of tests that run with weaving enabled, so I need to see how they fare with this new setup. Since if they are woven, aspects will apply, and if those aspects have dependencies we need those in AOPDependencyBuilder. >>>>>> >>>>>> >>>>>> On 24 Dec 2009, at 10:47, Ales Justin wrote: >>>>>> >>>>>> >>>>>>>> +1, disable AOP wherever possible. >>>>>>>> >>>>>>> I guess we can go the other way now, disabled by default + make >>>>>>> lifecycle completely OO. >>>>>>> We should then definitely see good improvement. >>>>>>> >>>>>>> >>>>>>>> And I'd even dare say if you want @JMX, why not just >>>>>>>> implement it the old fashion with MBean interfaces? It's simple and fast :-) >>>>>>>> >>>>>>> You got that right, it's simple, probably too simple. ;-) >>>>>>> I think one would still like to use the real power of POJO and IoC and >>>>>>> just register it to MBeanServer for some simple admin/config. >>>>>>> >>>>>>> I dare to say I think you need to re-read this article :-) >>>>>>> * http://java.dzone.com/articles/a-look-inside-jboss-microconta-0 >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development >

I fixed the tests (to have unique archive names inside ear). Now all JBossWS tests pass against AS trunk, see 601 jobs at: http://jbossws.jboss.org:8180/hudson/ IOW MC upgrade is ok for JBossWS, no problems since now ;) Richard On 01/13/2010 03:45 PM, Brian Stansberry wrote: > If you have some spare cycles to try and analyze the cause of some of > those failures, it would be very helpful. If you find anything, the "MC > 2.2.x update" thread on this list is the best place to report them. > > On 01/13/2010 08:30 AM, Richard Opalka wrote: > >> Yes, >> >> it's nice it boots faster. >> However there are still some issues, e.g. >> http://jbossws.jboss.org:8180/hudson/job/NATIVE-CORE-AS-6.0.1-SUN-JDK-6/28/ >> that have to be addressed/identified :( >> >> Rio >>

Let's wait for Richard confirmation (he just left), but from his commits I think at least part of the problem was basically the same Carlo's mentioned in "Re: [jboss-dev] Integration of naming deployers failed" regarding modules names that need to be unique. Cheers Alessio Brian Stansberry wrote: > Can you give an example? If there was a change in AS behavior that > forced you to change your deployments, I'd like to understand better > what the change was. > > On 01/14/2010 05:40 AM, Richard Opalka wrote: > >> I fixed the tests (to have unique archive names inside ear). >> Now all JBossWS tests pass against AS trunk, see 601 jobs at: >> >> http://jbossws.jboss.org:8180/hudson/ >> >> IOW MC upgrade is ok for JBossWS, no problems since now ;) >> >> Richard >> >> On 01/13/2010 03:45 PM, Brian Stansberry wrote: >> >>> If you have some spare cycles to try and analyze the cause of some of >>> those failures, it would be very helpful. If you find anything, the "MC >>> 2.2.x update" thread on this list is the best place to report them. >>> >>> On 01/13/2010 08:30 AM, Richard Opalka wrote: >>> >>> >>>> Yes, >>>> >>>> it's nice it boots faster. >>>> However there are still some issues, e.g. >>>> http://jbossws.jboss.org:8180/hudson/job/NATIVE-CORE-AS-6.0.1-SUN-JDK-6/28/ >>>> that have to be addressed/identified :( >>>> >>>> Rio >>>> >>>> > > > >

With the recent upgrade of MC in AS trunk, the "default" config on my system now boots in around 23 seconds consistently. Before the upgrade it used to take somewhere around 30 to 33 seconds.

Btw, do you also get warnings with NPE when shutting down?

I confirm, 25 secs here, good :-) Btw, do you also get warnings with NPE when shutting down? 16:56:16,582 INFO [TomcatDeployment] undeploy, ctxPath=/jmx-console 16:56:16,623 WARN [ScopedKernelController] Error uninstalling from PreInstall: name=jboss.naming:module=jmx-console aliases=[java:module] state=Not Installed: java.lang.NullPointerException at org.jboss.kernel.plugins.dependency.ScopedKernelController.getContext(ScopedKernelController.java:143) at org.jboss.dependency.plugins.AbstractController.uninstallUnusedOnDemandContexts(AbstractController.java:1503) at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1463) at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1357) at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:704) at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:732) at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:617) at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.undeploy(BeanMetaDataDeployer.java:228) at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.undeploy(BeanMetaDataDeployer.java:58) at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalUndeploy(AbstractSimpleRealDeployer.java:69) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.undeploy(AbstractRealDeployer.java:117) at org.jboss.deployers.plugins.deployers.DeployerWrapper.undeploy(DeployerWrapper.java:204) at org.jboss.deployers.plugins.deployers.DeployersImpl.doUndeploy(DeployersImpl.java:1690) at org.jboss.deployers.plugins.deployers.DeployersImpl.doUninstallParentLast(DeployersImpl.java:1597) at org.jboss.deployers.plugins.deployers.DeployersImpl.doUninstallParentLast(DeployersImpl.java:1590) at org.jboss.deployers.plugins.deployers.DeployersImpl.uninstall(DeployersImpl.java:1552) at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:384) at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1890) at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1456) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:892) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:602) at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:811) at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:654) at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117) at org.jboss.system.server.profileservice.repository.ProfileDeployAction.uninstall(ProfileDeployAction.java:95) at org.jboss.system.server.profileservice.repository.AbstractProfileAction.uninstall(AbstractProfileAction.java:70) at org.jboss.system.server.profileservice.repository.AbstractProfileService.uninstall(AbstractProfileService.java:417) at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:384) at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1890) at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1456) at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1357) at org.jboss.dependency.plugins.AbstractController.uninstallUnusedOnDemandContexts(AbstractController.java:1540) at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1463) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:892) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:602) at org.jboss.system.server.profileservice.repository.AbstractProfileService.deactivateProfile(AbstractProfileService.java:448) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.shutdown(ProfileServiceBootstrap.java:326) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.shutdown(ProfileServiceBootstrap.java:100) at org.jboss.bootstrap.impl.base.server.AbstractServer.shutdownBootstraps(AbstractServer.java:892) at org.jboss.bootstrap.impl.base.server.AbstractServer.shutdown(AbstractServer.java:309) at org.jboss.Main$ShutdownHook$1.run(Main.java:893) Jaikiran Pai wrote: > With the recent upgrade of MC in AS trunk, the "default" config on my > system now boots in around 23 seconds consistently. Before the upgrade > it used to take somewhere around 30 to 33 seconds. > > -Jaikiran > > Kabir Khan wrote: > >> I forgot to mention the changes that I did for JBKERNEL-75, i.e. lifecycle: http://community.jboss.org/message/518409#518409 >> >> The gist of it is that<lifecycle-configure/> & friends no longer can take an 'expr' attribute (containing a pointcut) and that the 'classes' attribute now must take an annotation. >> >> On 5 Jan 2010, at 18:08, Kabir Khan wrote: >> >> >>> The work for this has been committed against https://jira.jboss.org/jira/browse/JBKERNEL-75 and https://jira.jboss.org/jira/browse/JBKERNEL-74. I have a few things I need to do before the end of the week, if I have any time I'll try to see what impact this has on AS boot time. >>> On 4 Jan 2010, at 17:28, Kabir Khan wrote: >>> >>> >>>> I tried starting AS with the updated jboss-aop-mc-int.jar, but ran into problems with dependencies. I'll work on the @JMX stuff next, and try to see if I can update all the dependencies locally in AS once I'm done with that if I have some time before our release >>>> >>>> On 4 Jan 2010, at 15:43, Kabir Khan wrote: >>>> >>>> >>>>> I think I've got the bypassing proxy stuff working now both with and without weaving. I'm re-running some tests before committing. A summary of what I have done; >>>>> >>>>> -AOP proxy creation/checks is disabled by default >>>>> -@EnableAopProxy on a bean forces it to go through the proxy checks >>>>> -@DisableAOP is deprecated, but will stil be checked if it is present and the new annotations are not present >>>>> >>>>> A few points: >>>>> -if a bean is not woven but has constructor aspects you want invoked, the bean needs the @EnableAopProxy annotation >>>>> -If a bean's class is woven it can have aspects, so we will always check the AOP dependencies for that bean. This will only happen if loadtime weaving was turned on (or compile-time weaving was used) AND the bean matches some pointcuts, so it should not be an issue in practice. >>>>> >>>>> Once I've tidied up I'll commit to MC trunk, and try putting it into AS trunk before moving on to replacing the mechanism for AOP lifecycle. >>>>> >>>>> On 24 Dec 2009, at 12:29, Kabir Khan wrote: >>>>> >>>>> >>>>>> I've made a start on this, but doubt I'll finish it before I finish for Christmas. I am deprecating the @DisableAOP annotation. By default aop proxies will be disabled, but can be enabled with @EnableAopProxy. Lifecycle callbacks will be enabled by default (and I'll come up with a quicker way of determining if they should apply), but can be disabled using the @DisableAopLifecycle annotation. >>>>>> >>>>>> One issue that I need to look into is that there are a bunch of tests that run with weaving enabled, so I need to see how they fare with this new setup. Since if they are woven, aspects will apply, and if those aspects have dependencies we need those in AOPDependencyBuilder. >>>>>> >>>>>> >>>>>> On 24 Dec 2009, at 10:47, Ales Justin wrote: >>>>>> >>>>>> >>>>>>>> +1, disable AOP wherever possible. >>>>>>>> >>>>>>> I guess we can go the other way now, disabled by default + make >>>>>>> lifecycle completely OO. >>>>>>> We should then definitely see good improvement. >>>>>>> >>>>>>> >>>>>>>> And I'd even dare say if you want @JMX, why not just >>>>>>>> implement it the old fashion with MBean interfaces? It's simple and fast :-) >>>>>>>> >>>>>>> You got that right, it's simple, probably too simple. ;-) >>>>>>> I think one would still like to use the real power of POJO and IoC and >>>>>>> just register it to MBeanServer for some simple admin/config. >>>>>>> >>>>>>> I dare to say I think you need to re-read this article :-) >>>>>>> * http://java.dzone.com/articles/a-look-inside-jboss-microconta-0 >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 >> > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development >

Bill, did you make any measurements with AOP being turned off by default? ATM every bean is checked for bindings unless @DisableAOP is specified, it should probably be the other way round.