Using the LTS version is sadly not an option - I would definitely prefer that. But with our amount of projects and builds it takes a couple of hours to even start Jenkins because the lazy-loading fix was not yet released at that time.
To give you a small example how ridiculous the "triggered-by-upstream" data can be please take a look to the following job: http://jenkins.willowgarage.com:8080/job/ros-groovy-pr2-object-manipulation_binarydeb_precise_amd64/98/consoleFull Since I don't have any experience with the Jenkins sources myself I am pretty sure that my attempt to fix the issue would take a much longer time that any Jenkins developer and is likely not nearly as clean as it should be to be accepted upstream. - Dirk On Thursday, January 17, 2013 6:49:08 PM UTC-8, Mark Waite wrote: > > If it is urgent to disable the feature and the feature was added in 1.482, > you could consider installing the long term release, which is curently > 1.480.2. > > I'm impressed that you're running 5000 jobs with 30 executors and not > using the long term support release. The tip of Jenkins development is > surprisingly stable, but with 5000 jobs, even a little instability seems > like it could be a major disruption. > > You could also fork the Jenkins repository, prepare the change you're > suggesting, and submit a pull request. I did something like that with the > git plugin and found the process surprisingly friendly, even for me. > > Thanks, > Mark Waite > > ------------------------------ > *From:* "[email protected] <javascript:>" > <[email protected]<javascript:> > > > *To:* [email protected] <javascript:> > *Sent:* Thursday, January 17, 2013 5:09 PM > *Subject:* Logging UpstreamCause floods Jenkins - need to optionally > disable that feature > > I raised this question already on the users mailing list and filled a bug > reports months ago. > Since I got no response yet and consider my issue a pretty severe one I am > reposting it to the dev list. > > In version 1.482 the feature "Report root causes of UpstreamCause in log > and status pages" has been added. In certain scenarios (as stated > below) this is absolutely not feasible because the amount of data logged > per build might become dozens of megabytes (sometimes hundreds). The result > is that the jobs folder grows for several thousand builds in tens of > gigabytes (within a couple of hours) which lets Jenkins hit memory limits > and become unusable (even on a machine with 64GB of memory). > > Some more words on the scenario which shows that problem. We have a > Jenkins instance with 30 executors, and about 5000 jobs. I think the > specific thing is that these jobs are not independent (or slightly > connected) but have a lot of up/downstream relationships. The problem is > that when Jenkins hits one of the leaf jobs the list of hierarchic causes > which triggered that job is tens of megabytes long (I am not attaching a > full log I guess the content is pretty obvious). On the one hand because > the nesting level is very high and on the other hand since there are > several paths through the dependency graph. > > [Conceptionally it looks even weird that Jenkins tries to keep all these > data in memory - but that might be more difficult to fix in the short-term.] > > So there is an urgent need to optionally disable that feature. As > mentioned I already filled a ticket about that: > https://issues.jenkins-ci.org/browse/JENKINS-15747 > Since this is basically making Jenkins unusable in such scenarios can this > be handled with priority? > > - Dirk > > >
