Bug 819043 - Avoid calling Thread.getContextClassloader() to improve performance
Avoid calling Thread.getContextClassloader() to improve performance
Status: VERIFIED
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: BRE (Expert, Fusion) (Show other bugs)
BRMS 5.3.0.GA
All All
unspecified Severity urgent
: ER7
: BRMS 5.3.0.GA
Assigned To: Edson Tirelli
Lukáš Petrovický
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-04 12:30 EDT by Edson Tirelli
Modified: 2012-06-05 02:18 EDT (History)
2 users (show)

See Also:
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: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBRULES-3489 Major Closed Avoid calling Thread.getContextClassloader() to improve performance 2016-01-13 11:37 EST

  None (edit)
Description Edson Tirelli 2012-05-04 12:30:15 EDT
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 17:21:25 EDT
   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 10:27:04 EDT
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 10:59:04 EDT
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 12:54:31 EDT
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 04:15:43 EDT
The fixed for this issue should be included in ER7. Please do verification on it.
Comment 8 Lukáš Petrovický 2012-05-22 04:41:56 EDT
The fix is in and didn't break anything in ER7.
Comment 9 lcarlon 2012-06-05 02:17:48 EDT
    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.

Note You need to log in before you can comment on or make changes to this bug.