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
|