[jboss-dev] jbossas -beans.xml opt

[Jaikiran Pai]

Just to see how much improvement this brings in to AS boot time and how 
much efforts it takes to use the @DisableAOP, i tried a few things on 
5_x branch:

1) Since the AOPDependencyBuilder is meant for things like @JMX, i just 
searched for the number of files that need this support. In the 
"default" profile we have 10 files (ignore deployers.xml and jmx.xml for 
now):

./server/default/deploy/remoting-jboss-beans.xml
./server/default/deploy/vfs-jboss-beans.xml
./server/default/deploy/jca-jboss-beans.xml
./server/default/deploy/jbossweb.sar/META-INF/jboss-beans.xml
./server/default/deploy/transaction-jboss-beans.xml
./server/default/deploy/messaging/messaging-jboss-beans.xml
./server/default/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml
./server/default/conf/bootstrap/deployers.xml
./server/default/conf/bootstrap/jmx.xml
./server/default/deployers/jsr77-deployers-jboss-beans.xml


The "all" profile  has a few more (in clustering).

So out of all the MC beans that are being deployed (there are a lot) 
there's only 10 files (and not all MC beans in this file might need @JMX 
support) in the default profile for which the AOPDependencyBuilder 
probably makes sense.

2) So the next obviously was to add @DisableAOP to rest of all the 
-jboss-beans.xml which don't need the AOPDependencyBuilder. Obviously, 
this is not easy since there are a lot. And as and when we start adding 
new MC beans there's no guarantee that the developer even "remembers" to 
add this @DisableAOP.

3) I decided to instead patch in a code to use a new annotation 
@EnableAOP which could be used for beans which need the 
AOPDependencyBuilderSupport. So i just have to edit 8 files in the 
default profile. The other advantage of this approach is that when a 
developer is trying to get the @JMX (or some similar) support working 
and if he doesn't get it working then he sure will "remember" to add 
@EnableAOP (on the lines of "configuration by exception").

4) Edited 8 files to add @EnableAOP at <deployment> level (i could have 
added at a specific MC bean level in that file, but this was just for 
testing).

5) Updated the jboss-aop-mc-int.jar in %JBOSS_HOME%/lib to use the 
patched code

6) Booted the server. Here are the numbers with and without changes:

*Without* the AOPDependencyBuilder fix - consistently takes *23 seconds*:

20:30:10,457 INFO  [AbstractServer] Started: 
org.jboss.bootstrap.impl.as.server.JBossASServerImpl at 12b7eea in 23s:177ms

*With* the AOPDependencyBuilder fix using @EnableAOP - consistently 
takes around *21.5 seconds*

So 1.5 seconds improvement with changing around 10 files. 1.5 seconds 
might not sound too big an improvement, but it definitely is an improvement.

So the real question is which is the sensible default - at DisableAOP 
(which requires a lot of changes and everyone most of the time needs to 
remember they have to disable this support) or is it @EnableAOP (which 
makes more sense IMO).

regards,
-Jaikiran



Brian Stansberry wrote:
> If not, that re-opens the discussion as to whether @DisableAOP should 
> be required, or should be default behavior with an @EnableAOP. Since 
> AFAICT the thing that made me thing enabling it was required for the 
> common case was @JMX.
>
> Ales Justin wrote:
>> I don't think we need AOPBD for this. Kabir?
>>
>> Hmmm, perhaps something like this should be on the @DisableAOP:
>> @DisableAOP(allow={INSTANTIATE})
>> which would mean we don't use AOPDB - since the aspect we expect with 
>> this bean don't have any dependencies,
>> but we do want AOP proxy instantiation, since we *do* expect the bean 
>> to be aspectized.
>>
>> Jason T. Greene wrote:
>>> Ok, so then, why do we need AOPDependencyBuilder to use @JMX? Yes I 
>>> know the dep builder allows for users to add aspects after the fact, 
>>> but this is a near *useless* feature, especially for our core 
>>> components.
>>>
>>> Brian Stansberry wrote:
>>>> The registration of the @JMX handling is in the bootstrap, in 
>>>> bootstrap/jmx.xml.
>>>>
>>>> Jason T. Greene wrote:
>>>>> Ales Justin wrote:
>>>>>> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>>>>>>
>>>>>> This one instructs MC to ignore transparent AOP usage when 
>>>>>> handling your bean.
>>>>>> It will not look for aspect dependencies or try to create an AOP 
>>>>>> proxy.
>>>>>> It will simply fall back to plain POJO handling.
>>>>>>
>>>>>> If you use @JMX or anything similar, this should then *not* be used.
>>>>>> But for anything else it should be good to use it.
>>>>>
>>>>> Can we fix the @JMX (and other known cases) by deploying them 
>>>>> sooner, as part of the bootstrap for example?
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>
>>>>
>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
>