I know the majority of the polymorphic stuff is working fine right now. But now that you bring it up I'm kinda wondering why. It very we'll be possible that the way in which I'm discovering extensible types precludes it from AOP matching the beans. (Which isn't bad. We should only use AOP for declarative transaction management ideally. AOP on a project this size is most always a bad idea). The AOP is far more selective now anyhow. Only beans of GenericDaoBase and those that have @ActionEvent are being matched which isn't really any of the extensible types that require instanceof checks. Regardless I'll dig into exactly what is happening and give you an answer to be sure that issue won't hit us.
I've done extensive profiling on this. The heap and permgen are slightly less than what they used to be. I've been running -Xmx256mb for all my testing. Heap analysis shows that with all plugins (including noredist), permgen is at about 120mb and heap usage is about 150mb. Regarding the start up time, it is slightly slower. It's about 5 seconds slower to start on my laptop than before. I traced down the problem to AOP. Because I'm selectively looking for @ActionEvent it has to evaluate every method on every bean, which is slow. I know how to optimize it such that the startup can actually be faster than what it was before, but I really want to focus on correctness over speed right now. Cglib is no longer used for AOP. The only use of cglib now is in GenericDaoBase when it creates the VOs and also in the async framework. I should point out all of these changes apply only to the mgmt server. Awsapi and usage server are untouched. I did not have time to convert them too. So those still use ACS AOP and the monolithic config (which uses component scanning, so nobody remove @Component unless your really sure it's not used). Darren > On Oct 2, 2013, at 4:39 PM, Kelven Yang <kelven.y...@citrix.com> wrote: > > Darren, > > This looks really nice. A few questions on Spring AOP replacement. > > 1) Spring AOP is proxy-based, the reason we ended up of using customized > AOP is mainly due to that inside existing CloudStack codebase, we have > many places that are doing run-time type-casting, the code in these places > assumes a real object that implements all interfaces in the semantics > context. At the time when I initially converted to Spring, I couldn't > ensure that switching to proxy-based AOP can have 100% coverage for these > run-time cases. What is your approach to address this run-time > type-casting issue? > > 2) We've run into a huge-memory footprint issue that may be caused by > conflicts of CGLIB usage in Spring AOP and the CGLIB usage in CloudStack > Dao layer. Do you have a chance to run a memory analysis in the heap after > management server is started. > > I might be good to run BVT test on the branch before the merge, could > someone initiate the effort? > > kelven > > > >> On 10/2/13 3:48 PM, "Darren Shepherd" <darren.s.sheph...@gmail.com> wrote: >> >> Not sure how this works... I would like to merge in the new >> modularized Spring setup to master. There is info on the wiki about it >> [1] [2] [3]. The primary change is to break apart the monolithic >> applicationContext.xml and componentContext.xml files such that each >> plugin can maintain and contribute its own configuration. >> >> In addition to breaking up the configuration we no longer use ACS >> custom AOP and it is now fully Spring AOP. >> >> Now adding/removing a plug-in is a matter of just adding a jar to the >> classpath (exception being commands.properties, I'll address that in a >> different thread). Unfortunately this branch does not have the >> changes to package things in different RPMs. So it would be great if >> somebody could take up the packaging effort to split out all the >> plugins into different RPMs. >> >> Darren >> >> [1] >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Modularize+Spring >> [2] >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Plug-ins%2C+Modules >> %2C+and+Extensions >> [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Extensions >
