-
1. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
bkeh12 Apr 14, 2006 10:43 PM (in response to clebert.suconic)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 Apr 15, 2006 5:58 AM (in response to clebert.suconic)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 Apr 15, 2006 6:03 AM (in response to clebert.suconic)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 Apr 15, 2006 6:56 AM (in response to clebert.suconic)Hi,adrian
Thank for you help.
I will try it. -
5. Re: JBMICROCONT-74 - Testcases for redeployments using JVMTI
adrian.brock Apr 15, 2006 7:09 AM (in response to clebert.suconic)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 Apr 15, 2006 11:34 AM (in response to clebert.suconic)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 Apr 15, 2006 12:33 PM (in response to 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 Apr 16, 2006 11:00 AM (in response to clebert.suconic)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 Apr 16, 2006 10:22 PM (in response to clebert.suconic)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 Apr 17, 2006 12:21 AM (in response to 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 Apr 17, 2006 1:10 AM (in response to 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
adrian.brock Apr 17, 2006 5:18 AM (in response to clebert.suconic)"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 Apr 17, 2006 10:50 AM (in response to 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
adrian.brock Apr 17, 2006 10:56 AM (in response to clebert.suconic)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.