to sketch problem little:
using liferay portal solution our websites , add functionality , fix bugs using aspects within portal. amount of aspects on it's own not problem on startup amount of classloaders start weaving @ times is.
liferay uses jruby perform sass evalution on css files. each css file gets processed gets it's own jruby classloader (my knowledge of jruby limited don't know if way supposed work or not). has result if alot of css/jruby actions executed @ same time memory can jump 1.5gb , make jvm run out of memory. if jvm survives initial jump or if not many files processed @ same time memory use returns normal after while. problem caused memory overhead weaving process
in trying find solution came several changes can done. i'm not sure better 1 , if of options possible.
- there way exclude classloaders getting processed aspectj. in case jrubyclassloader ( found after searching think not possible)
- can jruby limited use 1 classloader in way reduce weaving overhead, if mean jruby can serial processing wouldn't problem
- recursivly limit classes weaven aspectj (don't think exclude in aop.xml way go add cflow limitation each aspect individually)
i pretty sure configuration in aop.xml file way go. see https://www.eclipse.org/aspectj/doc/next/devguide/ltw-configuration.html want use exclude option.
an example documentation:
<weaver options="-verbose"> <!-- weave types within javax.* or org.aspectj.* packages. weave types in foo package not have @noweave annotation. --> <include within="javax.*"/> <include within="org.aspectj.*"/> <include within="(!@noweave foo.*) , foo.*"/> <!-- not weave types within "bar" pakage --> <exclude within="bar.*"/> <!-- dump types within "somepack" package, both before after woven, "./_ajdump" folder on disk (for diagnostic purposes) --> <dump within="somepack.*" /> </weaver> 
Comments
Post a Comment