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

    JBMICROCONT-74 - Testcases for redeployments using JVMTIInte

    clebert.suconic

      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
          bkeh12

          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

            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

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

              • 4. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
                bkeh12

                Hi,adrian

                Thank for you help.
                I will try it.

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

                  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
                    bkeh12

                    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

                      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
                        bkeh12

                        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
                          bkeh12

                          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

                            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

                              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

                                 

                                "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

                                  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

                                    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