Bug 819043

Summary: Avoid calling Thread.getContextClassloader() to improve performance
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: Edson Tirelli <etirelli>
Component: BRE (Expert, Fusion)Assignee: Nobody <nobody>
Status: VERIFIED --- QA Contact:
Severity: urgent Docs Contact:
Priority: unspecified    
Version: BRMS 5.3.0.GA   
Target Milestone: ER7   
Target Release: BRMS 5.3.0.GA   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
When a JBoss BRMS instance is deployed into Gigaspaces container with the Java Security Manager enabled, accessing the context classloader is an extremely heavy operation (over 400 times slower) and caused thread contention among different threads running different sessions. This issue was resolved by removing the thread context class loader references from MVEL consequence execution.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Edson Tirelli 2012-05-04 16:30:15 UTC 
Description of problem:
When a Drools instance is deployed into Gigaspaces container with the Java Security Manager enabled, accessing the context classloader is an extremely heavy operation (over 400 times slower) and also causes thread contention among different threads running different sessions. In order to work around this problem, change the code to avoid accessing the context classloader as much as possible, without compromising thread safety.

Version-Release number of selected component (if applicable):
All version 5.x versions

How reproducible:
Requires Gigaspaces container with Java Security Manager on, but it is possible to check the performance degradation on any container with Java Security Manager on.
Comment 2 Edson Tirelli 2012-05-04 21:21:25 UTC 
   Sorry, poor choice of words from my part. We are not really breaking any security protocols here. It is just that everytime a java application calls the method Thread.currentThread().getContextClassloader(), it will hit the security manager if one is present. See the method implementation on JDK:

    public ClassLoader getContextClassLoader() {
        if (contextClassLoader == null)
            return null;
        SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
            ClassLoader ccl = ClassLoader.getCallerClassLoader();
            if (ccl != null && ccl != contextClassLoader &&
                    !contextClassLoader.isAncestor(ccl)) {
                sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION);
            }
        }
        return contextClassLoader;
    }

   What we are doing is, instead of calling that method all the time, we pass the classloader reference around avoid hitting the security manager all the time.
Comment 3 Edson Tirelli 2012-05-07 14:27:04 UTC 
Code changes pushed into the 5.3.x branch:

<GitHub81> [drools] etirelli pushed 1 new commit to 5.3.x: https://github.com/droolsjbpm/drools/commit/cfe72930aa72b8027259f3c47ca656b2c9703087
<GitHub81> [drools/5.3.x] JBRULES-3489: Removing Thread Context Class Loader references from MVEL Consequence execution - Edson Tirelli

Still requires the update to the new MVEL jar.
Comment 4 Edson Tirelli 2012-05-07 14:59:04 UTC 
Mario just pushed the update of the pom.xml to the new mvel version dependency jar into 5.3.x branch:

<GitHub159> [droolsjbpm-build-bootstrap] mariofusco pushed 1 new commit to 5.3.x: https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/commit/1250d2deb0d81380fc686c2f5265a493de85e7bc
<GitHub159> [droolsjbpm-build-bootstrap/5.3.x] [JBRULES-3489] upgrade mvel version - mariofusco
Comment 5 Edson Tirelli 2012-05-07 16:54:31 UTC 
FYI, as discussed by e-mail, the following build can be used to test the changes we made for this ticket on top of ER6:

http://hudson.qa.jboss.com/hudson/job/drools-5.3.x/438/artifact/drools-distribution/target/

Requires only the drools-core jar and the MVEL jar to be replaced on your ER6 binaries:

drools-core-5.3.2-SNAPSHOT.jar
mvel2-2.1.0.drools16.jar
Comment 6 Ryan Zhang 2012-05-14 08:15:43 UTC 
The fixed for this issue should be included in ER7. Please do verification on it.
Comment 8 Lukáš Petrovický 2012-05-22 08:41:56 UTC 
The fix is in and didn't break anything in ER7.
Comment 9 lcarlon 2012-06-05 06:17:48 UTC 
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When a JBoss BRMS instance is deployed into Gigaspaces container with the Java Security Manager enabled, accessing the context classloader is an extremely heavy operation (over 400 times slower) and caused thread contention among different threads running different sessions. This issue was resolved by removing the thread context class loader references from MVEL consequence execution.