-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Hudson 1.385 and previous; ClearCase plugin 1.2.1; Solaris 10; JDK 1.6u17; ClearCase 7.0.0.8
When SCM polling takes a long time to complete - that is to the order of 30mins. Hudson starts to leak memory.
I stopped polling the diretory tree that had the massive set of changes and this immediately stabilised the memory usage.
see hudson_leak.bmp - the red line shows the time when ClearCase polling (lshist) was taking a long time, the green line shows the time I update the load rules of the snapshot view in order to avoid scanning for the huge change set.
Only a few projects out of say 50 in my config were polling for this change set, but that was enough.
Hmmmm I've just noticed that there are polling activities reported by Hudson that don't have any corresponding threads on the build server - in this case the master for example. Eventually the ghost polling activities dissapear too off the list and the mast Hudson JVM was able to recover ~1GB of heap.
see hudson_leak_2.png