1 2 Previous Next 25 Replies Latest reply on Apr 21, 2006 2:53 AM by chung chung

    JBMICROCONT-74 - Testcases for redeployments using JVMTIInte

    Clebert Suconic Master

      bkeh12 (BTW, what's your name or nick name), if you could attach your testcase here:

      http://jira.jboss.org/jira/browse/JBMICROCONT-74

      Then we could talk about this with some more information.

        • 1. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
          chung chung Newbie

          I'm Attach it.
          I'm not sure whether test is correct.
          So wonder whether MC have MemoryLeaks.
          Sorry if it is naughtily,Please excuse me.

          ps:
          I think reflect's MetaData in MC like database which is used by bean's MetaData to create bean.
          So undeploy in MC is bean not class,and that deploy version's is supported.

          • 2. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
            Adrian Brock Master

            This test is not correct.
            Its never going to be correct while the test itself holds a reference to the class/classloader
            import org.jboss.test.classinfo.support.SimpleBean;

            • 3. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
              Adrian Brock Master

              A simpler and more complete test would be to deploy/undeploy
              a your.beans into jboss4

              • 5. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
                Adrian Brock Master

                You could just run the MC part of the testsuite
                then use Clebert's memory profiling tool.

                cd testsuite
                ./build.sh test -Dtest=kernel -Dnojars=t
                


                • 6. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
                  chung chung Newbie

                  Hi,
                  I run the MC part of the testsuite then use Clebert's memory profiling tool.
                  I haven't see MemoryLeaks.
                  Clebert,is that right ?

                  Run1
                  22:20:15,296 INFO [STDOUT] SimplePOJO create
                  22:20:15,296 INFO [STDOUT] SimplePOJO start
                  22:20:15,343 INFO [STDOUT] SimplePOJO stop
                  22:20:15,343 INFO [STDOUT] SimplePOJO destroy
                  
                   Class Number Of Instances Size in Bytes ClassLoader
                  org.jboss.test.kernel.deployment.jboss.beans.simplepojo.SimplePOJO 0 0 org.jboss.mx.loading.UnifiedClassLoader3 objectTag=6216
                  
                  Run2
                  22:46:35,515 INFO [STDOUT] SimplePOJO create
                  22:46:35,515 INFO [STDOUT] SimplePOJO start
                  22:46:35,562 INFO [STDOUT] SimplePOJO stop
                  22:46:35,562 INFO [STDOUT] SimplePOJO destroy
                  
                   Class Number Of Instances Size in Bytes ClassLoader
                  org.jboss.test.kernel.deployment.jboss.beans.simplepojo.SimplePOJO 0 0 org.jboss.mx.loading.UnifiedClassLoader3 objectTag=6216
                  
                  Run3
                  22:56:20,156 INFO [STDOUT] SimplePOJO create
                  22:56:20,156 INFO [STDOUT] SimplePOJO start
                  22:56:20,218 INFO [STDOUT] SimplePOJO stop
                  22:56:20,218 INFO [STDOUT] SimplePOJO destroy
                  Run4
                  22:58:32,421 INFO [STDOUT] SimplePOJO create
                  22:58:32,437 INFO [STDOUT] SimplePOJO start
                  22:58:32,484 INFO [STDOUT] SimplePOJO stop
                  22:58:32,484 INFO [STDOUT] SimplePOJO destroy
                  
                   Class Number Of Instances Size in Bytes ClassLoader
                  org.jboss.test.kernel.deployment.jboss.beans.simplepojo.SimplePOJO 1 24 org.jboss.invocation.http.server.HttpInvokerMBean objectTag=6374
                  org.jboss.test.kernel.deployment.jboss.beans.simplepojo.SimplePOJO 0 0 sun.reflect.GeneratedConstructorAccessor14 objectTag=6424
                  org.jboss.test.kernel.deployment.jboss.beans.simplepojo.SimplePOJO 0 0 javax.management.j2ee.statistics.Statistic objectTag=6366
                  org.jboss.test.kernel.deployment.jboss.beans.simplepojo.SimplePOJO 0 0 sun.reflect.ConstructorAccessorImpl objectTag=6413
                  
                  


                  But Run3,Run4 problems may be in profiling.

                  • 7. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
                    Clebert Suconic Master

                    I will have to make few tests myself... but on Monday :-)

                    But the test is not valid, you have or to use reflection on everything, using the created classloader, or to use what Kabir created in top of my test and call the testcase with the created classLoader. If you don't use reflection the classLoader used will be the same classLoader that loaded the testcase thus the test is not valid.

                    • 8. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
                      chung chung Newbie

                      Hi,Adrian

                      I had updated DeploymentClassLoaderTestCase to make test.
                      I'm attach it to jira.(McMemoryLeaksTest.zip)
                      Forget my stupid,I'm not sure whether test is correct.
                      But it hasn't fail within Clebert's test.
                      So wonder whether MC have MemoryLeaks.
                      Sorry if it is naughtily,Please excuse me.

                      thank

                      • 9. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
                        chung chung Newbie

                        Sorry,Fixup the DeploymentClassLoaderTestCase's tearDown()

                        
                        public class DeploymentClassLoaderTestCase extends AbstractDeploymentTest
                        {
                         .......
                        
                         public void tearDown() throws Exception
                         {
                         undeploy("DeploymentClassLoaderTestCase.xml"); //undeploy to work twice ...
                         checkUnload(weakReferenceOnLoader,"org.jboss.test.kernel.deployment.support.SimpleBeanImpl");
                         super.tearDown();
                        
                         }
                        
                         ........
                        }
                        


                        • 10. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
                          Clebert Suconic Master

                          What Adrian meant by a deployment testcase was to deploy a microcontainer into JBoss/Tomcat and test for redeployments.

                          I have changed your original test and it's working now, what means there is no leakages.

                          Anyway, I'm kind of concerned on replicating this test all over the place without a super class. I will create a supe class on JBossTestCase, and them commit the test.

                          • 11. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
                            Clebert Suconic Master

                            I just commited the testcase.

                            You will need o update /test first as there is a super class JBossMemoryTestCase into /test project.

                            If you execute the testcase:

                            ant -f build-test.xml memory-test

                            You will have this result:

                            memory-test:
                             [junit] Running org.jboss.test.memorytests.ClassInfoMemoryTestCase
                             [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.37 sec
                            



                            I have even added a test looking for too weak scenarions, and I didn't find any problem at al:

                            
                             JVMTIInterface jvmti = new JVMTIInterface();
                             if (jvmti.isActive())
                             {
                             jvmti.forceGC();
                             assertEquals(1,jvmti.getAllObjects(ClassInfo.class).length);
                             }
                            
                            


                            What means that even after releasing all instances of ClassInfo, and keeping references to the ClassLoader the classInfo still referenced.

                            I have even changed forceGC to forceReleaseOnSoftReferences on my local copy (in case any SoftReference is being used by mistake) and this is not causing any problem.


                            So, in case anyone has any more suggestions I would close the JIRA.

                            Adrian, would you like to test anything else besides the meta data here?

                            If not, I will close the JIRA.

                            Regards,


                            Clebert

                            • 12. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
                              Adrian Brock Master

                               

                              "clebert.suconic@jboss.com" wrote:

                              Anyway, I'm kind of concerned on replicating this test all over the place without a super class. I will create a supe class on JBossTestCase, and them commit the test.


                              The JBossTestCase class is for integration tests with JBoss.
                              If you are testing integration it belongs in the testsuite not in the MC unit tests.

                              • 13. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
                                Clebert Suconic Master

                                I created /test/org.jboss.test.JBossMemoryTestCase as a super class for these tests.

                                Every time I'm creating these tests I needed the methods I have on that class. Even the AOP ones are using these methods and I will probably refactor to use a super class.

                                I don't think (at least I don't know if it is) the project /test under jboss-head is used for integration tests only as I have seen EJB3 and AOP using super classes from /test. If you want to avoid the dependency, please let me know what you want me to do.

                                • 14. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
                                  Adrian Brock Master

                                  The test project contains all the abstract tests.

                                  Some people (EJB3/AOP) want to write their own integration tests
                                  (a bad idea in my opinion) which means the base integration tests have to live
                                  in /test to avoid recursive build problems.

                                  Others don't want to share their test infrastructure and just write their own
                                  which just creates a bigger learning curve for everybody else.

                                  I've given up trying to fix this. e.g. EJB3 recently reintroduced a recursive build problem
                                  with their dependency on the clustering test framework that only exists in testsuite.

                                  1 2 Previous Next