Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 899291 (JBPAPP6-365)

Summary: Performance risk: Inefficient synchronization in ENCFactory
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Radoslav Husar <rhusar>
Component: OtherAssignee: Andrig Miller <andy.miller>
Status: CLOSED WONTFIX QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: ales.justin, jpai, jwhiting, rhusar
Target Milestone: ---   
Target Release: EAP 6.0.0   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/JBPAPP6-365
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-22 09:03:16 UTC 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:
Attachments:
Description Flags
tree.png
none
threads.png
none
syncmap.diff none

Description Radoslav Husar 2010-08-03 16:52:37 UTC
project_key: JBPAPP6

During JNDI lookup naming test, I found that ENCFactory seems to be uselessly synchronized in getObjectInstance method.

The important part, Context compCtx = (Context) classloaderKeyedEncs.get(ctxClassLoader) is synchronized by classloaderKeyedEncs which means that every simple get() call is synchronized leading to thread congestion in cases of concurrent JNDI lookups. It is responsible for roughly 3% of total thread blocking (in a heavy JNDI lookup test).

Example diff using synchronized map via Collections is attached. Here is the original code:

   // ObjectFactory implementation ----------------------------------
   public Object getObjectInstance(Object obj, Name name, Context nameCtx,
      Hashtable environment)
      throws Exception
   {
      Object currentId = encIdStack.get();
      if (currentId != null)
      {
         Context compCtx = encById.get(currentId);
         if (compCtx == null)
         {
            compCtx = createContext(environment);
            encById.put(currentId, compCtx);
         }
         return compCtx;
      }
      // Get naming for this component
      ClassLoader ctxClassLoader = GetTCLAction.getContextClassLoader();
      synchronized (classloaderKeyedEncs)
      {
         Context compCtx = (Context) classloaderKeyedEncs.get(ctxClassLoader);

         /* If this is the first time we see ctxClassLoader first check to see
          if a parent ClassLoader has created an ENC namespace.
         */
         if (compCtx == null)
         {
            ClassLoader loader = ctxClassLoader;
            GetParentAction action = new GetParentAction(ctxClassLoader);
            while( loader != null && loader != topLoader && compCtx == null )
            {
               compCtx = (Context) classloaderKeyedEncs.get(loader);
               loader = action.getParent();
            }
            // If we did not find an ENC create it
            if( compCtx == null )
            {
               compCtx = createContext(environment);
               classloaderKeyedEncs.put(ctxClassLoader, compCtx);
            }
         }
         return compCtx;
      }
   }

http://anonsvn.jboss.org/repos/jbossas/projects/naming/tags/5.0.3.GA/jnpserver/src/main/java/org/jboss/naming/ENCFactory.java

Comment 1 Radoslav Husar 2010-08-03 16:53:17 UTC
Attaching graphs and a diff.

Comment 2 Radoslav Husar 2010-08-03 16:53:17 UTC
Attachment: Added: tree.png
Attachment: Added: threads.png
Attachment: Added: syncmap.diff


Comment 3 Radoslav Husar 2010-08-04 10:44:44 UTC
Automatically assigning, not sure who would be handling naming.

Comment 4 Radoslav Husar 2010-08-04 10:45:20 UTC
Link: Added: This issue is related to JBPAPP-4786


Comment 5 Radoslav Husar 2010-08-04 15:33:11 UTC
Link: Added: This issue is a dependency of JBPAPP-4654


Comment 7 Jason Greene 2010-08-17 16:25:51 UTC
A fix has been developed in 5.6.0.CR1 that uses a non-blocking algorithm with slightly slower memory reclamation. If this turns out to be an issue we can make it more aggressive which will make writes a bit slower. This however does not make the 5.1 schedule, so it will be put into community first and brought into a future EAP release

Comment 8 Rajesh Rajasekaran 2010-10-06 15:35:20 UTC
As discussed on the performance call on Oct5th, assigning to Andy to implement improvements in this area upstream and drive it for EAP6

Comment 9 Jason Greene 2010-10-06 16:16:03 UTC
Hi Andy,

Email me if you have any questions, but you can see my changes in the most recent version of naming. It has not had heavy testing, my main concern is to verify that memory reclamation is fast enough. This can be improved as mentioned above, although yet another solution is we can add a global reclamation thread to periodically purge this table.

Comment 10 Andrig Miller 2012-02-21 20:05:56 UTC
I'm resolving this as out of date, due to the fact that we have an entirely new code base for this.

Comment 11 Radoslav Husar 2012-02-22 09:03:16 UTC
Agreed, closing.