Fisheye 3.7.1
16G Heap
4x CPU
1 / 2 indexing threads configuration
Mostly SVN repos, some Git
Since our recent upgrade to 3.7.1, Fisheye has gotten into a state where a few threads will run constantly, saturating the CPU. After a restart, it calms down and then after some time, hours or days, will abruptly consume all of the CPU cores again (and not let go).
Fisheye is usable right now (after a restart) but there has been one constant thread consuming one CPU since the restart. What is its purpose? When the CPU cores become saturated, and Fisheye becomes unusable, there are several of these similarly-named threads competing for CPU:
Thread:
qtp1351478315-1318 [1318] (RUNNABLE)
Stack Trace
com.cenqua.fisheye.diff.MyersOND.buildPath line: 123
com.cenqua.fisheye.diff.MyersOND.diff line: 82
com.cenqua.fisheye.diff.Diff.diff line: 8
com.cenqua.fisheye.diff.DiffHelper.getHunkList line: 27
com.cenqua.fisheye.diff.DiffHelper.getHunkList line: 142
com.cenqua.crucible.revision.source.Source.getHunkList line: 230
com.cenqua.crucible.view.FRXDO.getHunkList line: 1287
com.cenqua.crucible.view.FRXDO.getTetrisGrid line: 781
com.cenqua.crucible.view.FRXDO.mapInlineComments line: 809
com.cenqua.crucible.view.FRXDO.<init> line: 204
com.cenqua.crucible.revision.managers.DefaultContentManager.makeFRXDO line: 114
com.atlassian.crucible.actions.ReviewBaseAction.makeFRXDO line: 597
com.atlassian.crucible.actions.ViewFRXAction.execute line: 188
...
GC is not an issue, not even when Fisheye becomes non-responsive. We have a 16G heap that collects down to 6G and there is no thrashing (of GC).
What is the purpose of this thread? Can we correct something to remedy the CPU utilization or is it necessary to assign more processors to this machine?
