On 09/10/2012 01:50 PM, nicolas de loof wrote:
Cobertura plugin (that can have huge report data to store in memory) uses a WeakReference to avoid OOME, but generally speaking all build data indeed increase memory footprint. Many widget (trends) need access to build history data, so some lazy-loading strategy should not help here. Best practice or new design considerations are welcome
Ideally a given AbstractBuild instance would hold very little in heap, so that you could scalably loads hundreds of them. The log file is already stored as a disk file and served on demand. The question is whether other actions can be made to also keep large data off the heap.
JUnit test results are another major culprit. The use of XML as the persistent storage does not make it straightforward to retrieve individual pieces of information, such as the status of a given test in a given build, much less perform larger calculations such as test trends. Perhaps some kind of lightweight database, or RandomAccessFile / mapped ByteBuffer, could help this situation, if plugins were updated to keep per-build information in it? This would be moving toward some kind of abstraction over Jenkins instance storage, in place of the current getRootDir() free-for-all.
