7 Replies Latest reply on Sep 10, 2009 2:13 PM by Ales Justin

    Classloader and hot deployment 5.1

    Tarek Hammoud Novice

      Hello,

      We have a very simple application deployed as an ear file. When we hot deploy the ear, everything seems to work fine except for a native library. This library is accessed using one of the jar files embedded in the ear. The error that we get is as follows:

      Caused by: java.lang.UnsatisfiedLinkError: Native Library XYZ.so already loaded in another classloader

      isolated property is set to its default value of false. When you hot deploy, it seems like a new class loader is created for the new deployment. Thus the error above. We have no need to ever run different versions of the app at the same type. Is there some option to effectively discard everything about the old ear and redeploy the new ear?

      There are a bewildering set of options and any help will be greatly appreciated. Thank you in advance.

        • 1. Re: Classloader and hot deployment 5.1
          jaikiran pai Master

          Please post the entire exception stacktrace.

          While posting logs or xml content or code, please remember to wrap it in a code block by using the Code button in the message editor window. Please use the Preview button to ensure that your post is correctly formatted.

          • 2. Re: Classloader and hot deployment 5.1
            Tarek Hammoud Novice

            My apologies. Here it goes.

            11:28:56,959 ERROR [Report] java.lang.UnsatisfiedLinkError: Native Library /relmgt/tools/mathlib/redhat_linux_9_64_bit_v11.1/lib/libCJavaWrap.so already loaded in another classloader
            java.lang.RuntimeException: java.lang.UnsatisfiedLinkError: Native Library /relmgt/tools/mathlib/redhat_linux_9_64_bit_v11.1/lib/libCJavaWrap.so already loaded in another classloader
             at com.enfusion.report.engine.ReportEngine.buildReport(ReportEngine.java:215)
             at com.enfusion.fas.feeds.report.Report$EventProcessorImpl.processUserMessage(Report.java:281)
             at com.enfusion.report.event.ASynchronousEventDispatcher.processUserMessageNow(ASynchronousEventDispatcher.java:129)
             at com.enfusion.fas.feeds.report.Report.start(Report.java:183)
             at com.enfusion.fas.feeds.report.ReportFeed.processSubscribe(ReportFeed.java:76)
             at com.enfusion.feed.server.AbstractFeedHandler.subscribe(AbstractFeedHandler.java:381)
             at com.enfusion.feed.server.AbstractFeedMessageDispatcher.processSubscribe(AbstractFeedMessageDispatcher.java:138)
             at com.enfusion.feed.server.AbstractFeedMessageDispatcher.access$300(AbstractFeedMessageDispatcher.java:32)
             at com.enfusion.feed.server.AbstractFeedMessageDispatcher$DispatchMessageRunnable.run(AbstractFeedMessageDispatcher.java:222)
             at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
             at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
             at java.lang.Thread.run(Thread.java:619)
            Caused by: java.lang.UnsatisfiedLinkError: Native Library /relmgt/tools/mathlib/redhat_linux_9_64_bit_v11.1/lib/libCJavaWrap.so already loaded in another classloader
             at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1743)
             at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1703)
             at java.lang.Runtime.loadLibrary0(Runtime.java:823)
             at java.lang.System.loadLibrary(System.java:1028)
             at com.mathlib.ShowAll.<clinit>(ShowAll.java:1593)
             at com.enfusion.fds.util.MATHLIBUtils.serialFromYearMonthDay(MATHLIBUtils.java:133)
             at com.enfusion.fds.util.PositionReportDates.adjust(PositionReportDates.java:140)
             at com.enfusion.fds.util.PositionReportDates.<init>(PositionReportDates.java:53)
             at com.enfusion.fas.scenario.ScenarioGenerator.getAllDates(ScenarioGenerator.java:146)
             at com.enfusion.fas.scenario.ScenarioGenerator.generate(ScenarioGenerator.java:59)
             at com.enfusion.fas.providers.position.PositionReportDataSource.keys(PositionReportDataSource.java:444)
             at com.enfusion.report.engine.ReportEngine.buildReport(ReportEngine.java:193)
             ... 11 more
            


            • 3. Re: Classloader and hot deployment 5.1
              jaikiran pai Master

               

              Caused by: java.lang.UnsatisfiedLinkError: Native Library /relmgt/tools/mathlib/redhat_linux_9_64_bi
              t_v11.1/lib/libCJavaWrap.so already loaded in another classloader
               at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1743)
               at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1703)
               at java.lang.Runtime.loadLibrary0(Runtime.java:823)
               at java.lang.System.loadLibrary(System.java:1028)


              Looking at this stracktrace and the way the native libraries are loaded, i don't see a way you can hot deploy the application successfully, unless you move this piece of code outside the package being hot deployed. Infact, a google search for this error shows up similar issues and some workarounds.


              • 4. Re: Classloader and hot deployment 5.1
                Tarek Hammoud Novice

                As usual, we truly appreciate your prompt replies.

                I guess I do not understand how hot deployment works. I thought that by deleting the ear, I am asking whatever class loader that loaded all the items in the ear to discard everything. When I redeploy, a new fresh copy is loaded. My question is, why is a class loader still has this class loaded? It also has other static classes loaded.

                • 5. Re: Classloader and hot deployment 5.1
                  jaikiran pai Master

                   

                  I guess I do not understand how hot deployment works. I thought that by deleting the ear, I am asking whatever class loader that loaded all the items in the ear to discard everything. When I redeploy, a new fresh copy is loaded.


                  That's what is happening infact. A fresh copy of your deployment classes is loaded in a different classloader. However, for some reason java.lang.ClassLoader does not allow the native library to be loaded by this different loader.

                  See "Native library problems" section here http://onjava.com/pub/a/onjava/2004/06/30/classloader2.html

                  • 6. Re: Classloader and hot deployment 5.1
                    Tarek Hammoud Novice

                    I took out the vendor jar file and placed it in lib and that fixed the problem. Will it be possible to still include the jar in the ear file but somehow tell the class loader to use the system class loader for that particular jar file? This will greatly ease our deployments. Thank you very much.

                    • 7. Re: Classloader and hot deployment 5.1
                      Ales Justin Master

                       

                      "thammoud" wrote:
                      Will it be possible to still include the jar in the ear file but somehow tell the class loader to use the system class loader for that particular jar file?

                      You can add new custom deployer that creates ClassLoader(Factory).
                      In your case it would return system ClassLoader.

                      See ClassLoaderFactory and its usage in AbstractClassLoaderDeployer.
                      e.g. your custom deployer would add ClassLoaderFactory to unit's attachments if the unit equals your special jar