OFBiz
  1. OFBiz
  2. OFBIZ-4335

Delegator creation fails with new ExecutionPool on trunk

    Details

      Description

      he creation of the delegator done in GenericDelegator fails for me, when starting ofbiz or running run-install-exttest. This is the exception I am getting for each delegator

      [java] 2011-07-08 10:15:17,691 (ofbiz-config-2) [ GenericHelperFactory:62 :WARN ]
      [java] ---- exception report ----------------------------------------------------------
      [java] Exception: java.lang.ClassNotFoundException
      [java] Message: org.ofbiz.entity.datasource.GenericHelperDAO
      [java] ---- stack trace ---------------------------------------------------------------
      [java] java.lang.ClassNotFoundException: org.ofbiz.entity.datasource.GenericHelperDAO
      [java] java.net.URLClassLoader$1.run(URLClassLoader.java:202)
      [java] java.security.AccessController.doPrivileged(Native Method)
      [java] java.net.URLClassLoader.findClass(URLClassLoader.java:190)
      [java] java.lang.ClassLoader.loadClass(ClassLoader.java:307)
      [java] java.lang.ClassLoader.loadClass(ClassLoader.java:248)
      [java] org.ofbiz.entity.datasource.GenericHelperFactory.getHelper(GenericHelperFactory.java:60)
      [java] org.ofbiz.entity.GenericDelegator.initializeOneGenericHelper(GenericDelegator.java:268)
      [java] org.ofbiz.entity.GenericDelegator.access$000(GenericDelegator.java:89)
      [java] org.ofbiz.entity.GenericDelegator$1.call(GenericDelegator.java:287)
      [java] org.ofbiz.entity.GenericDelegator$1.call(GenericDelegator.java:285)
      [java] java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
      [java] java.util.concurrent.FutureTask.run(FutureTask.java:138)
      [java] java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
      [java] java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
      [java] java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
      [java] java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
      [java] java.lang.Thread.run(Thread.java:680)
      [java] --------------------------------------------------------------------------------

      When removing the ExecutionPool specific code which returns the Callable stuff from the GenericDelegator everything gets back to work, so there might be some problem.

      Reply from doogie:

      It's the Thread.currentThread().getContextClassLoader() call in
      GenericHelperFactory that is broken.

        Activity

        Hide
        Jacques Le Roux added a comment -

        Thanks Martin,

        Your slighlty augmented patch is in
        trunk r1435701
        R12.04 r1435705
        R11.04 r1435731
        R10.04 r1435740

        I also remored the deprecated methods and it contains a change Jacopo did at r1361955, it was a nightmare to merge else

        Show
        Jacques Le Roux added a comment - Thanks Martin, Your slighlty augmented patch is in trunk r1435701 R12.04 r1435705 R11.04 r1435731 R10.04 r1435740 I also remored the deprecated methods and it contains a change Jacopo did at r1361955, it was a nightmare to merge else
        Hide
        Jacques Le Roux added a comment -

        I confirm Martin's solution doesmake sense and works well. At least, with the case he proposed you can recreate the issue, and his fix cures it.

        I don't see any issues, but performance, to not start the whole core threads. This is BTW the default behaviour. So I'd recommend to use it for GLOBAL_EXECUTOR.

        So I believe it's a good idea to apply this patch. I also think it would be a good thing to remove the deprecated methods which are no used anywhere.

        I will wait a week and will apply this patch if nobody is concerned

        Show
        Jacques Le Roux added a comment - I confirm Martin's solution doesmake sense and works well. At least, with the case he proposed you can recreate the issue, and his fix cures it. I don't see any issues, but performance, to not start the whole core threads. This is BTW the default behaviour. So I'd recommend to use it for GLOBAL_EXECUTOR. So I believe it's a good idea to apply this patch. I also think it would be a good thing to remove the deprecated methods which are no used anywhere. I will wait a week and will apply this patch if nobody is concerned
        Hide
        Jacques Le Roux added a comment -

        Without reactions I will reassign to me and apply one of the above (did not reven re-read yet)

        Show
        Jacques Le Roux added a comment - Without reactions I will reassign to me and apply one of the above (did not reven re-read yet)
        Hide
        Jacques Le Roux added a comment -

        Bump?

        Show
        Jacques Le Roux added a comment - Bump?
        Hide
        Martin Kreidenweis added a comment -

        Just checking up on the ticket status...

        Do you need more info or did you just not get around to applying the patch yet?

        I still would suggest just disabling the pre-starting of the ofbiz-config threads. The code then behaves the same regardless whether the UtilPropertiesResourceCache timeout is set or not.

        I don't think the ThreadWithClassLoader that Adam suggested is necessary.

        Show
        Martin Kreidenweis added a comment - Just checking up on the ticket status... Do you need more info or did you just not get around to applying the patch yet? I still would suggest just disabling the pre-starting of the ofbiz-config threads. The code then behaves the same regardless whether the UtilPropertiesResourceCache timeout is set or not. I don't think the ThreadWithClassLoader that Adam suggested is necessary.
        Hide
        Martin Kreidenweis added a comment -

        I have an alternate, very simple patch:

        Index: framework/base/src/org/ofbiz/base/concurrent/ExecutionPool.java
        ===================================================================
        --- framework/base/src/org/ofbiz/base/concurrent/ExecutionPool.java	(Revision 1144132)
        +++ framework/base/src/org/ofbiz/base/concurrent/ExecutionPool.java	(Arbeitskopie)
        @@ -39,7 +39,7 @@
         @SourceMonitored
         public final class ExecutionPool {
             public static final String module = ExecutionPool.class.getName();
        -    public static final ScheduledExecutorService GLOBAL_EXECUTOR = getExecutor(null, "ofbiz-config", -1, true);
        +    public static final ScheduledExecutorService GLOBAL_EXECUTOR = getExecutor(null, "ofbiz-config", -1, false);
         
             protected static class ExecutionPoolThreadFactory implements ThreadFactory {
                 private final ThreadGroup group;
        
        

        The problem is indeed that the wrong class loader is used for the "ofbiz-config-*" threads (NativeLibClassLoader instead of CachedClassLoader). This happens when the threads are created by the static code in ExecutionPool.java when it is executed before the ClassLoaderContainer.init() initializes the CachedClassLoader.

        This also causes other problems like: The local resolution of XML Schema files won't work any more because it's also using the wrong classloader, which can't find the XSD files:

        [java] 2011-07-21 12:21:45,333 (ofbiz-config-0) [                 UtilXml:1022:WARN ] [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema with publicId [null] and the file/resource is [service-eca.xsd]
        

        You can trigger this behavior in current ofbiz trunk by setting an expire time for the properties cache in cache.properties

        properties.UtilPropertiesResourceCache.expireTime=10000
        

        The Debug.log() statements in the ContainerLoader then load the logging configuration properties file and cache it. If an expire time is set, the ExecutionPool is used and creates the "ofbiz-config-*" threads too early.

        By not pre-starting the "ofbiz-config-*" threads in the static code (patch above), the threads are then created later on, when the "main" thread classloader has become the CachedClassLoader and everythings starts working again.

        Show
        Martin Kreidenweis added a comment - I have an alternate, very simple patch: Index: framework/base/src/org/ofbiz/base/concurrent/ExecutionPool.java =================================================================== --- framework/base/src/org/ofbiz/base/concurrent/ExecutionPool.java (Revision 1144132) +++ framework/base/src/org/ofbiz/base/concurrent/ExecutionPool.java (Arbeitskopie) @@ -39,7 +39,7 @@ @SourceMonitored public final class ExecutionPool { public static final String module = ExecutionPool.class.getName(); - public static final ScheduledExecutorService GLOBAL_EXECUTOR = getExecutor( null , "ofbiz-config" , -1, true ); + public static final ScheduledExecutorService GLOBAL_EXECUTOR = getExecutor( null , "ofbiz-config" , -1, false ); protected static class ExecutionPoolThreadFactory implements ThreadFactory { private final ThreadGroup group; The problem is indeed that the wrong class loader is used for the "ofbiz-config-*" threads ( NativeLibClassLoader instead of CachedClassLoader ). This happens when the threads are created by the static code in ExecutionPool.java when it is executed before the ClassLoaderContainer.init() initializes the CachedClassLoader . This also causes other problems like: The local resolution of XML Schema files won't work any more because it's also using the wrong classloader, which can't find the XSD files: [java] 2011-07-21 12:21:45,333 (ofbiz-config-0) [ UtilXml:1022:WARN ] [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema with publicId [ null ] and the file/resource is [service-eca.xsd] You can trigger this behavior in current ofbiz trunk by setting an expire time for the properties cache in cache.properties properties.UtilPropertiesResourceCache.expireTime=10000 The Debug.log() statements in the ContainerLoader then load the logging configuration properties file and cache it. If an expire time is set, the ExecutionPool is used and creates the "ofbiz-config-*" threads too early. By not pre-starting the "ofbiz-config-*" threads in the static code (patch above), the threads are then created later on, when the "main" thread classloader has become the CachedClassLoader and everythings starts working again.
        Hide
        Alexander Reelsen added a comment -

        Applying this patch worked as far as there were no exceptions on normal startup or running run-install-exttest.

        Show
        Alexander Reelsen added a comment - Applying this patch worked as far as there were no exceptions on normal startup or running run-install-exttest.
        Hide
        Adam Heath added a comment -

        Please try the attached patch(which is far away from the actual code that was shown in your stack trace). It applies to the current trunk(1144107).

        Show
        Adam Heath added a comment - Please try the attached patch(which is far away from the actual code that was shown in your stack trace). It applies to the current trunk(1144107).

          People

          • Assignee:
            Jacques Le Roux
            Reporter:
            Alexander Reelsen
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development