[jboss-dev] Further profling: Where should I focus?

[Brian Stansberry]

Are you interested in AS 6 in general, not just boot perf?

On 12/30/2009 06:22 PM, Bill Burke wrote:
>
>
> Ales Justin wrote:
>>> IMO, we should just remove AOP entirely as our customers probably are
>>>   not going to use it.
>>
>> This is exactly what will happen - remove AOP - if we disable it by
>> default and re-write lifecycle handling to plain OO, w/o any costly
>> pointcut matching.
>>
>> The only cost is lookup for potential @AOPEnable on the bean.
>> While we still keep optional cool feature of creating an AOP proxy for a
>> bean.
>>
>>> For @JMX just write another deployer and do it
>>>   regularly.  Similarly with lifecycle and other features.
>>
>> Regularly?
>> If you mean to register an mbean, that is actually not what we/users want.
>> See my response to Dimitris this morning.
>>
>
> There probably is a way to make AOP irrelevant to boot performance, but
> you need to consider pluses and minuses nevertheless...Everybody
> (thousands) of users are effected by boot performance, while only a
> handful care about @JMX, etc.
>
>> While this could be a deployer feature, I think it's far more complex to
>> do it than tie it into the bean's lifecycle.
>> e.g. scan for @JMX, remembering the handle, checking if it's overridden
>> for an instance, ... while we already have all this implemented in
>> bean's lifecycle handling, it's just not optimized yet.
>>
>> What do you mean by "similarly with lifecycle and other features"?
>> @JMX, @JNDI, @Password, ... is the lifecycle callback.
>>
>
> All these annotations that trigger AOP.  Are they under the jboss
> namespace?  Controlled by us?
>
> You might want to consider meta-annotations and turning @AOPEnabled into
> one. i.e.
>
> @AOPEnabled
> public @interface JMX {...}
>
> You look at the bean's class annotations, then look at those annotations
> for @AOPEnabled.
>
>>> Again, if you want to take this route, I'd be happy to do the work.
>>> I am willing to spend the next month on boot performance and AS.
>>
>> Excellent.
>> So will I and the rest of MC team.
>
> Well, I need to know what I could do to help.  Is Kabir fine on the AOP
> stuff?  VFS3 seems to be ok?  What about removing JMX Kernel Backward
> Compatibility and upgrading services to MC?  I can tackle any of these
> problems with little guidance I just don't want to be duplicating any
> work (like with the deployer sorting).
>


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat