cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <>
Subject Re: [MERGE] spring-modularization to master - Spring Modularization
Date Thu, 03 Oct 2013 01:09:41 GMT

On 10/2/13 5:52 PM, "Darren Shepherd" <> wrote:

>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. 
>> On Oct 2, 2013, at 5:40 PM, Darren Shepherd
>><> 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.


>>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
>> 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
>> 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 <> 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
>>> 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
>>> 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
>>> 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
>>> Dao layer. Do you have a chance to run a memory analysis in the heap
>>> 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" <>
>>>> 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, 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] 
>>>> [2] 
>>>> %2C+and+Extensions
>>>> [3]

View raw message