Kelvin, Also since I'm using dynamic proxies for AOP, spring is suppose to expose all interface of the target. But I'll still dig in and make sure 100% this is all good.
Darren > On Oct 2, 2013, at 5:40 PM, Darren Shepherd <darren.s.sheph...@gmail.com> > wrote: > > 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 >>
