September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-2909) Testcase infra structure for MemoryLeaks

by Clebert Suconic (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ] Clebert Suconic updated JBAS-2909: ---------------------------------- Assignee: Rajesh Rajasekaran (was: Clebert Suconic) > Testcase infra structure for MemoryLeaks > ---------------------------------------- > > Key: JBAS-2909 > URL: http://jira.jboss.com/jira/browse/JBAS-2909 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Clebert Suconic > Assigned To: Rajesh Rajasekaran > Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1 > > > We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test). > Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero. > Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache) > To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that). > This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler: > jvmtiInterface.forceReleaseOfGC(); > Class[] classes = jvmtiInterface.getLoadedClasses(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2909) Testcase infra structure for MemoryLeaks

by Clebert Suconic (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ] Clebert Suconic updated JBAS-2909: ---------------------------------- Comment: was deleted > Testcase infra structure for MemoryLeaks > ---------------------------------------- > > Key: JBAS-2909 > URL: http://jira.jboss.com/jira/browse/JBAS-2909 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Clebert Suconic > Assigned To: Clebert Suconic > Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1 > > > We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test). > Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero. > Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache) > To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that). > This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler: > This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler: > jvmtiInterface.forceReleaseOfGC(); > Class[] classes = jvmtiInterface.getLoadedClasses(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2909) Testcase infra structure for MemoryLeaks

by Clebert Suconic (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ] Clebert Suconic updated JBAS-2909: ---------------------------------- Comment: was deleted > Testcase infra structure for MemoryLeaks > ---------------------------------------- > > Key: JBAS-2909 > URL: http://jira.jboss.com/jira/browse/JBAS-2909 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Clebert Suconic > Assigned To: Clebert Suconic > Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1 > > > We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test). > Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero. > Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache) > To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that). > This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler: > This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler: > jvmtiInterface.forceReleaseOfGC(); > Class[] classes = jvmtiInterface.getLoadedClasses(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2909) Testcase infra structure for MemoryLeaks

by Clebert Suconic (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ] Clebert Suconic updated JBAS-2909: ---------------------------------- Description: We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test). Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero. Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache) To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that). This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler: jvmtiInterface.forceReleaseOfGC(); Class[] classes = jvmtiInterface.getLoadedClasses(); was: We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test). Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero. Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache) To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that). This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler: This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler: jvmtiInterface.forceReleaseOfGC(); Class[] classes = jvmtiInterface.getLoadedClasses(); > Testcase infra structure for MemoryLeaks > ---------------------------------------- > > Key: JBAS-2909 > URL: http://jira.jboss.com/jira/browse/JBAS-2909 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Clebert Suconic > Assigned To: Clebert Suconic > Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1 > > > We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test). > Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero. > Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache) > To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that). > This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler: > jvmtiInterface.forceReleaseOfGC(); > Class[] classes = jvmtiInterface.getLoadedClasses(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2909) Testcase infra structure for MemoryLeaks

by Clebert Suconic (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ] Clebert Suconic updated JBAS-2909: ---------------------------------- Description: We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test). Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero. Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache) To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that). This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler: This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler: jvmtiInterface.forceReleaseOfGC(); Class[] classes = jvmtiInterface.getLoadedClasses(); was: We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test). Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero. Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache) To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that). > Testcase infra structure for MemoryLeaks > ---------------------------------------- > > Key: JBAS-2909 > URL: http://jira.jboss.com/jira/browse/JBAS-2909 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Clebert Suconic > Assigned To: Clebert Suconic > Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1 > > > We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test). > Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero. > Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache) > To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that). > This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler: > This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler: > jvmtiInterface.forceReleaseOfGC(); > Class[] classes = jvmtiInterface.getLoadedClasses(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2909) Testcase infra structure for MemoryLeaks

by Clebert Suconic (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ] Clebert Suconic updated JBAS-2909: ---------------------------------- Description: We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test). Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero. Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache) To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that). was: It's possible to use JVMTIInterface from JBossProfiler to validate if an undeployment is releasing classes, by doing assertions on certain queries made to JVMTI. Example: jvmtiInterface.forceGC(); Object[] classes = jvmtiInterface.getAllObjects(Class.class); Class classFound; for (int i=0;i<classes.length;i++) { Class theClass = (Class)classes[i]; if (theClass.getName().equals("org.jboss.test.SomeEJB")) { classFound=theClass; } } if (classFound) { fail("Undeployment couldn't clean org.jboss.test.SomeEJB"); } Of course that feature will be optional, and used in certain testcases only. This way we will assure that memory leaks are not introduced on tested places. Complexity: High > Testcase infra structure for MemoryLeaks > ---------------------------------------- > > Key: JBAS-2909 > URL: http://jira.jboss.com/jira/browse/JBAS-2909 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Clebert Suconic > Assigned To: Clebert Suconic > Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1 > > > We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test). > Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero. > Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache) > To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3696) WebServices leaking redeployment

by Clebert Suconic (JIRA)

WebServices leaking redeployment -------------------------------- Key: JBAS-3696 URL: http://jira.jboss.com/jira/browse/JBAS-3696 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Clebert Suconic Assigned To: Thomas Diesler Priority: Blocker Fix For: JBossAS-4.0.5.GA org.jboss.ws.metadata.UnifiedMetaData has lots of strong references to ClassLoader, and Undeployers are not releasing references to the metadata. The current failures we are having on the TestSuite (OOME) are related to this task. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
2
0 / 0

[JBoss JIRA] Assigned: (JBMESSAGING-185) Run objectweb JMS tests in top of JBoss Messaging

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-185?page=all ] Ovidiu Feodorov reassigned JBMESSAGING-185: ------------------------------------------- Assignee: Richard Achmatowicz > Run objectweb JMS tests in top of JBoss Messaging > ------------------------------------------------- > > Key: JBMESSAGING-185 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-185 > Project: JBoss Messaging > Issue Type: Task > Components: Tests and Performance > Reporter: Ovidiu Feodorov > Assigned To: Richard Achmatowicz > Fix For: 1.2.1 > > Original Estimate: 4 days > Remaining Estimate: 4 days > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-385) Generalize jboss testsuite JMS tests to work with both Messaging and JBossMQ (where possible) and make sure they pass

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-385?page=all ] Ovidiu Feodorov closed JBMESSAGING-385. --------------------------------------- Resolution: Duplicate Issue Duplicate of http://jira.jboss.org/jira/browse/JBMESSAGING-555 > Generalize jboss testsuite JMS tests to work with both Messaging and JBossMQ (where possible) and make sure they pass > --------------------------------------------------------------------------------------------------------------------- > > Key: JBMESSAGING-385 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-385 > Project: JBoss Messaging > Issue Type: Sub-task > Components: AS Integration > Reporter: Ovidiu Feodorov > Assigned To: Ovidiu Feodorov > Priority: Critical > Fix For: 1.2.1 > > > More details on how to do that: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=72570 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-386) Isolate JBossMQ-specific tests and make sure they pass

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-386?page=all ] Ovidiu Feodorov closed JBMESSAGING-386. --------------------------------------- Resolution: Duplicate Issue Duplicate of http://jira.jboss.org/jira/browse/JBMESSAGING-556 > Isolate JBossMQ-specific tests and make sure they pass > ------------------------------------------------------ > > Key: JBMESSAGING-386 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-386 > Project: JBoss Messaging > Issue Type: Sub-task > Reporter: Ovidiu Feodorov > Assigned To: Ovidiu Feodorov > Priority: Critical > Fix For: 1.2.1 > > > Move them inside the JBossMQ project as functional tests -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2006