On 2/23/12 9:04 AM, Nicolas Bros wrote:
Exactly what does keeping JUnit test results in memory mean? I assume it only keeps the Junit test report XML files chosen in "Publish JUnit test result report" in the job configuration. These can get big when the tests output a lot of text (stacktraces, log messages etc.)
Yes that is correct. To know exactly look at the XML file hudson creates at <job>/builds/<build-no>/junitResult.xml. If this file is large, then it is going to consume more memory.
- Winston
On Thu, Feb 23, 2012 at 5:52 PM, Ed Willink <[email protected] <mailto:[email protected]>> wrote:Hi After the build is done, Hudson keeps some of the build artifacts such as JUNit or maven metadata info. Since hudson keeps all the builds of all joba, this bloats up the memory. The immediate solution is reduce the foot print of these build artifacts, if we can. Long term term solution is fix Hudson not to keep all the builds in memory Exactly what does keeping JUnit test results in memory mean? For the MDT/OCL JUnit tests, the derived TestCase classes have fields that can reference useful and sometimes large models. These used to be a major source of 'leakage' and sometimes prevented tests running in 512M. After making sure that all fields were nulled in tearDown() they run in 32M. GMF Tooling uses MDT/OCL, so they may be encountering a similar form of model lock-in. Regards Ed Willink _______________________________________________ cross-project-issues-dev mailing list [email protected] <mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev-- Nicolas BrosR&D tel: 06 75 09 19 88 [email protected] [email protected] Mia-Software, 410 clos de la Courtine 93160 Noisy-le-Grand http://www.mia-software.com .: model driven agility :. <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
