> > 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.)
On Thu, Feb 23, 2012 at 5:52 PM, Ed Willink <[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 > cross-project-issues-dev@**eclipse.org<[email protected]> > https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev > > -- > Nicolas Bros > R&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> > <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
