EJBTHREE-1800 Improving InjectInterceptorsFactory

[jaikiran]

While working on EJBTHREE-1800, i noticed that the InjectInterceptorsFactory while creating a per joinpoint, does the following:

1) Retrieves *all* methods on the interceptor/bean class
2) For each of these methods, checks whether it's overridden
3) If not, then checks whether the method has an @AroundInvoke

This currently leads to a performance degradation. As the number of methods increase (on the bean or the interceptor class), so does the timing of this logic.

Keeping in mind, the following requirements in the EJB3 spec:

AroundInvoke methods have the following signature: Object (InvocationContext) throws Exception

the logic in this InjectInterceptorsFactory can be improved as follows:

1) Get only those methods with accept InvocationContext as a param type and return type is Object (internally we still have to scan all public, private, package etc... methods of the class as per the spec, but filtering out the relevant methods will help in step#2 and #3)
2) For each of these (filtered) methods which follow the AroundInvoke method signature, check if it has a @AroundInvoke declared
3) If there's a @AroundInvoke, then go on to check whether the method is overridden. If yes, ignore.

Initial local tests with this change, does show some good improvements. Any other thoughts?

[jaikiran]

One more place which i think can be improved for performance is the InterceptorRegistry, which currently checks for the presence of any @Interceptor and @InterceptorOrder on the bean classes/methods. Currently, the InterceptorRegistry does the following for method-level logic:

1) Get *all* (public, private, protected etc...) methods on the bean class
2) For each of these methods check for the presence of @Interceptors
3) Build a collection of Interceptor classes applicable to this method (which effectively is default intereceptors, class interceptors and any interceptors declared for that method)
4) Check for the presence of @InterceptorOrder on each of these methods

I think we can improve this logic. The EJB3 spec says:

"EJB3 Spec, Section 12.7" wrote:
A business method interceptor method may be defined to apply to a specific business method invocation, rather than to all of the business methods of the bean class.

So we can improve step#1 to:

1) Get only public methods of a bean class and its super classes (since a business method cannot be anything other than public). This effectively eliminates a lot of irrelevant methods from further processing

No change in logic for step#2 and #3
2) For each of these methods check for presence of @Interceptors
3) Build a collection of Interceptor classes applicable to this method (which effectively is default intereceptors, class interceptors and any interceptors declared for that method)

A bit of improvement in step#4
4) Only if the collection of interceptor classes for this method is non-empty, then go ahead with the check for @InterceptorOrder. If there are no relevant interceptors for this method then there's no point in checking the @InterceptorOrder


I haven't given this change a try yet - will do now. But any thoughts about this change?

[wolfc]

If there is no regression push it forward.

[jaikiran]

"jaikiran" wrote:

A bit of improvement in step#4
4) Only if the collection of interceptor classes for this method is non-empty, then go ahead with the check for @InterceptorOrder. If there are no relevant interceptors for this method then there's no point in checking the @InterceptorOrder

I missed the point that @InterceptorOrder is applicable at class level too. So i am not going to add this "improvement" in step#4.

Other than that, with the rest of the changes, the unit tests in interceptors are passing.

[jaikiran]

Done as part of https://jira.jboss.org/jira/browse/EJBTHREE-1801 and will be available in this week's release.