-
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.
[JENKINS-8189] When a major change set occurs in ClearCase causing log SCM polls, Hudson leaks memory
banoss
created issue -
banoss
made changes -
| Attachment | New: hudson_leak_2.png [ 20042 ] |
| Workflow | Original: JNJira [ 138292 ] | New: JNJira + In-Review [ 174863 ] |
| Assignee | Original: Vincent Latombe [ vlatombe ] | New: Eficode [ eficode ] |
Tatu Kairi
made changes -
| Assignee | Original: Eficode [ eficode ] |
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