On 10/2/13 5:52 PM, "Darren Shepherd" <darren.s.sheph...@gmail.com> wrote:
>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. I brought it up just for cautious reason, since I know we have quite many places that do run-time type check and casting, it relies heavily on the semantic that the target object should be 100% compatible to real object if there is proxy business involved. One of the other reason is that since these are run-time checks, testing without enough coverage may not reveal all the problems. -Kelven >>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+Sprin >>>>g >>>> [2] >>>> >>>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Plug-ins%2C+Modu >>>>les >>>> %2C+and+Extensions >>>> [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Extensions >>>
