Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

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

Crucible failing to index even 1 SVN revision

I have a crucible instance running over a single SVN repo. It has historically worked, recently it has started failing to index. I have tried reducing the number of revisions to even the single most recent entry and it is failing to index. It scans all revisions easily, but sticks at the start of the idex process.

I have tried index, full reindex, manually deleting the whole index and I get the same issues. It appears to just get stuck and eventually Java just uses all the memory on the box until no-one can get in at all.

2 answers

I would look at your heap size and object allocation using an APM tool or heap analyzer.

Do the logs indicate any errors before it crashes?

It may be a big revision is causing a number of objects to force excessive Garbage Collection. You can try increasing heap, but I would only suggest that if you see memory issues.

0 votes
Nick Atlassian Team Mar 23, 2014

Which changeset is it getting stuck on ?

Can you please have a look at that changeset, and see if it involves many many paths ? How many ?

Definitely consider:

  1. increasing the JVM heap as suggested by Eddie Webb above
  2. setting a start revision in the repo settings, to be one higher than the problem revision.
    1. this will mean earlier history will not be indexed, searchable, etc

Also be aware that we are fixing such issues with FishEye all the time, and the most recent version of FishEye/Crucible 3.3.2 should be used. 3.4.0 coming out in mid-April will also contain improvements in the area of indexing extremely large changesets.

Further, you could send the java process a SIGQUIT (kill -3) to get a couple of heap dumps and see what is happening prior to the OOME.

Also, you could capture a MemoryDump on OOME, and try and get that to us for investigation.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Marketplace Apps & Integrations

Do Not Lose your Customer’s Trust

Missing deadlines is one of the biggest problems every team lead wants to avoid when dealing with managed services. When the customer contracts your company to help with IT services it is expected th...

24 views 0 0
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