Polarion ALM stores all data in the Subversion repository. While this approach brings many advantages (history, branching, etc.), compared to traditional database approach it does entail some performance trade-offs. Polarion ALM uses advanced caching and indexing techniques to achieve acceptable performance levels. In most standard situations, the caching and indexing behaves transparently and users do not need to take care of it. However, the caching and indexing logic imposes certain restrictions and requirements for what users can and cannot do. This section explains these limitations in more detail.
The following events initiate index updating:
Commits to the Subversion repository (including changes initiated by Polarion)
Polarion start-up
The index contains information about location of all entities (work items, etc.) in the repository and their history, so the term "index" refers to more things then just the index used by the Search feature. Rather it is the entire indexing scheme that enables optimal performance.
During the index update the Polarion checks all changes made to repository since the last indexed revision and update the index accordingly.
Changing sort order of an enumeration, dates of time points, etc. which are already referenced will cause inconsistency in the sorting. Some referrals will be sorted by to the old sort order, and some by the new. A complete index rebuild solves this problem.
Symptoms of a "broken" index tend to be the following: some work items are not up-to-date, some are missing, history cannot be viewed or shows invalid or truncated information.
You may not need to completely rebuild the index if you observe the above symptoms.
Run the pre-configured Index Refresher job (Projects portlet: Repository, Topics portlet: Monitor). This job corrects problems with information updating.
If number 1 above does not fix all symptoms, try running the Index Checker job. This job should bring back work items that are missing from view.
If the above steps do not fix the symptoms, then you will need to rebuild the index, as described in the next section.
The procedure may sometimes be referred to as "index rebuild", "rebuild index", "index synchronization", or "index rebuilding".
There are two important things for an administrator to keep in mind before initiating an index rebuild:
The Polarion server must be shut down before commencing an index rebuild
Depending on the size of the repository, reindexing time can range from a few minutes to several hours. End users will not be able to use the system during the reindexing process.
You should plan to perform any re-index operation at a time when system usage is low, and downtime is not critical for end users.
It is a good practice to back up the old index before reindexing. It is recommended to back up the directory data/workspace/polarion-data (relative to the Polarion installation root directory). The the cache, *-cache, and jobs sub-directories can be omitted from backup.
You perform the reindexing by running the appropriate reindexing script for your operating system:
Windows: polarion/reindex.bat
Linux: /etc/init.d/polarion reindex
Progress of the reindexing operation is reported in the console and written to a log file.
Do not interrupt the index rebuild process. The process writes messages to the console and the log4j-startup-TIMESTAMP.log log file. Check this file for the status of the process. As mentioned, with large repositories the index rebuild can take several hours, and it may seem that nothing is happening for long periods. Reindex must be restarted if interrupted. If you believe there may be a problem with the process, contact Polarion Software technical support before attempting to kill the reindex rebuild process.