| Hi Denis, Winston, all, 
 
 
      Right.  So I propose that the tycho-gmp.gmf.tooling
      job be moved over to our Sandbox so that its memory consumption
      does not impact our Hudson instance.  Any objections?How much trouble does this cause to other jobs? Is this job the only
    responsible for Hudson being slow? Would removing from Hudson save
    the world?
 If yes, then I think it is fair to move it TEMPORARLY to the sandbox
    while the issue is not fixed. But I'd be OK with that just if
    someone can promise to the GMF Tooling team that the issue (which is
    in GMF build? in GMF job? in Maven? in Hudson?) will be fixed in a
    short delay, otherwise the CI job for GMF Tooling will be forever in
    a sandbox, it'd have a bad effect on the project. Also, be sure that
    if GMF Tooling job is moved to sandbox, the same problem will happen
    on sandbox...
 If no, then it seems that the job does not cause real trouble, then
    let's keep it as it and keep on enjoying life while Hudson folks
    improve the memory consumption.
 
 Is there any benefit in blaming this job and moving it to sandbox?
 
 Winston,
 Correct me if I'm wrong, but since the build happens in a forked
    process in Hudson, it does not consume memory by itself. Then the
    problem is clearly in Hudson or one of its plugins, isn't it? So the
    Maven/Tycho build by itself is not the culprit. If the memory is
    consumed by Hudson JVM, then the issue in is Hudson.
 Is there something we could change in configuration of the job to
    make it consume less memory?
 About the tests, GMF-Tooling has 431 tests, I am not really sure.
    Some other projects probably have more tests on this Hudson instance
    and don't have the same problem. But maybe the content of test
    reports is bigger in GMF Tooling (more execution traces maybe?)
    causing this huge memory consumption.
 Any help is appreciated. You can get me on Skype: mickael.istria
 
 |