Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Why is this Fisheye thread consuming CPU cycles?

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:

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?

5 answers

More information: these threads start taking a full CPU core when a particular file is viewed in a review. The file is never viewable and the UI eventually times out. However, the thread never goes away. If we try to view that file in a review again (new window), a new thread pops up taking a full CPU core. Now we have 2X threads each taking up full CPU cores. We can keep doing this until the instance becomes non-responsive. The offending file is an xxx.sql file (with SQL content). We don't immediately see anything suspicious about it.

Update: The thread starts when the review begins to load. Before any file is selected to view. This review has only 3 files. The thread never stops. A different review, with 700+ files, does not cause this issue.

Likely this bug --, support could confirm that for you.

Hi Chad,

As Sergey mentioned from your description and stack trace it looks you're facing the issue described by, though you mentioned it happens even not loading any of the files.

For the review in which you observe this happening can you please confirm:

  • What's the size of the files added to the review.
  • How many revisions of these files are added to the review.

I've also asked for updates in CRUC-6593 in a private comment - please add yourself as a watcher to it so you can keep track of any progress on it.


Gustavo Refosco

Fisheye server appears to be very busy with the CPU pegged at 100% utilization. There are no other applications running on the machine that appear to be consuming resources. There are no apparent exceptions reported in the Fisheye logs. for any CPU related Problem to check out here:">Tv 


The FISHEYE_INST/config.xml has a similar configuration:


  <incrementalIndexThreads max="30"/>
  <initialIndexThreads max="300"/>
<crowd auto-add="true" resync="true" refreshExistingUsers="true" sso-enabled="
true" resyncPeriod="1 hour" jiraInstance="false">


Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Confluence

⚡️NEW Group for Confluence Cloud Admins

Calling all Confluence Cloud Admins!  We created a new Community Group to support your unique needs as Confluence admins. This is a group where you can ask questions, access resou...

79 views 2 7
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you