integrity check and indexing

[Helen Ahlberg]

We have the choise of running Background re-index or Lock JIRA and rebuild index. We have discovered that running Background re-index often causes trouble/problems for projects and they often stop working whilst the process is running.

What is Atlassian's advice for this? Is it better for us to perform Re-index project on the actual project that needs it after changes and can this action help us to avoid running a big indexing?

We now run an integrity check first followed by the Lock JIRA alternative to be sure that we do not cause problems for our projects. What is your recommendation?

[Nic Brough -Adaptavist-]

Start with the question of why this causes you a problem.  Re-indexing should be infrequent, and only really triggered when an admin is making field changes or has run into system problems.

A project re-index will do the basics if you're making field changes, assuming the field is limited by its context to that project.

[Helen Ahlberg]

Thanks for the answer.

We are making a lot of changes in the system and therefor needs to re-index periodically. We feel that the system slows down and even losese contact when we do the background index.

So if we stick to the fact that if we make a full indexing to the system (not in the background) and thereafter always run a project re-index when we make changes we should be fine? (And then not get the annoing message up to the right that suggest we perform indexing)

[Nic Brough -Adaptavist-]

Yes, indexing is an intensive process that chews up a lot of resources while it runs.

The advantage to project re-indexing is that it only does a sub-set of issues, so the process thrashes your system for a shorter time.  The background re-index can be thought of as "get list of projects, and click on re-index for each one, one at a time".

[Helen Ahlberg]

Can I please check with you what the difference is between these two ways of running indexing?

[Nic Brough -Adaptavist-]

There's more than two ways of indexing.  It's not quite this simple in reality, but unless you're coding, this is the easiest way to think of it:

• There's a chunk of code which reads the index for an issue.
• There's a chunk of code which reads an issue out of the database and creates a set of index entries for it, based on the "searcher" code for each field and attribute.
• When JIRA needs to index a single issue, it runs the "read index" code above, removes the existing data it finds for that issue from the index, then runs the "create" code for it.
• When you ask JIRA to run a project index, it does a SQL search for "all issues in this project" and runs the create code for each issue.
• When you ask JIRA to run a full background index, it does a SQL for "all issues" and runs the create code for each issue.
• When you ask JIRA to run a full locking index, it throws away the whole index and does a SQL for "all issues" and runs the create code for each issue

[Helen Ahlberg]

OK - thanks for this very explaining answer