Indexing Troubles
 

Depending on hardware and the volume format used, MailArchiva typically reindexes around five million documents per day. When clicking on Reindex All, MailArchiva will reindex one volume at a time until complete with all volumes. After clicking on the Reindex button, you should see the volume doc count rising in Status->Volumes. If the volume doc count does not increase, check the reindex log in Status->Tasks for errors. Failing that, examine the debug.log in Configuration->Logs for errors. 

1) Stop the MailArchiva service

2) Upgrade MailArchiva to the very latest version (important!)

3) Ensure there is ample free disk space available on the disk where the indexes are located.

4) Rename the parent index directory directly from filesystem. For example, if your volume indexes are stored in C:\index\index1, and C:\Index\index2, simply rename C:\Index_bak so that MailArchiva will recreate the index directory from scratch when started.

5) In each volume's store directory, open the volumeinfo file using a text editor. If there are .zz files present in a store directory, ensure the format line contains V2, "format:V2". Otherwise, set it is to "format:V1".

6) Start the server and reindex the affected volume in Configuration->Volumes.

7) If the doc counts increase in Status->Volumes, then the reindex is functioning correctly. Failing that, check the reindex log in Status->Tasks for errors.

If the above process does not fix the issue, then the other possibilities are as follows:

1) In each volume's store directory, open the volumeinfo file using a text editor. Each volumeinfo file must have a unique volume ID. If there are any overlapping volume IDs, then the volume logic will not function correctly. To resolve it, manually modify the conflicting overlapped volume ID to a random hex value. For example, change ff2623a3-b7da-493d-9456-53adae251cb0 to aa2623a3-b7da-493d-9456-53adae251cb1.

2) The other alternative is that your volumes are encrypted using a different encryption key. In this case, your volumes will need to be recrypted using a new key.

Disk Space

Verify that the server has enough disk space available.

Failed to Startup Index

Login to the Server Console, click Status->Alerts. if an error equivalent to "failed to start index" is present:

1. Take note of the index path referred to in the alert message.
2. Stop the server
3. Delete the contents of the affected volume's index directory from the file system directly (using explorer or bash shell)
4. Start the server
5. Reindex the volume in question

Wrong Encryption Password

A server may not be able to reindex a volume that is encrypted using a different password to the currently configured encryption password (in Configuration->Volumes).

All configured volumes must be encrypted using the same password that is defined in Configuration->Volumes. In such cases, when reindexing, the doc count will remain at zero, and decoding/decryption errors will be outputted in the debug.log file (see Configuration->Logs). The resolution is to re-encrypt the data to the configured encryption password. Refer to Reencrypt for further instructions.

Incorrect Volume Format Version

A volume will not be able to reindex if its format is reported incorrectly. A file called volumeinfo in the root of a volume's store path specifies the format version (either V1, V2 or V3). The volumeinfo file can be edited using a text editor such as Wordpad or vi. If the volume's store directory has .zz files present, the format should be set to V2. If there are .mrc files in the end-branches of sub-directories, then the format should be set to V1. If there are files present with no extensions, then set the volume format to V3. Unmount the volume in Configuration->Volumes, edit the volumeinfo file and change the volume format, mount the volume, and reindex the affected volume.

Attempt To Unlock Read Lock

The following error will appear in the reindex log accessible from Status->Processes.

2014-05-06 12:53:55,669 reindex 125482f9c75bb851 failed:attempt to unlock read lock, not locked by current thread

This is a known issue in v3.8.20. The resolution is to upgrade to 3.8.21. 

Slow Reindexing

• Ensure that the indexes reside on fast SAS drives / SSD drives
• Ensure that MailArchiva has enough available physical RAM and that the server's memory settings are configured correctly.
• Consider disabling indexing of attachments in Configuration->Index
• Try upgrading your version of MailArchiva to the latest version

Indexing of X400 Email Addresses

Some very old PST files may include emails with X400 addresses. See: http://techgenix.com/x400-addresses-exchange-2010-part1/. When importing PST files containing emails with X400 addresses, MailArchiva will archive the emails as is (i.e with their X400 addresses intact). However, when indexing the addresses, MailArchiva will try to convert the X400 addresses to SMTP format for simplified searching.

An X400 address is in the format "C=US;A= ;P=LetsExchange;O=First Organization;S=Mota;G=Nuno". If MailArchiva encounters such an X400 address, it will index it as nuno@letsexchange.com in message recipient/from address provided that letsexchange.com is listed as the first domain Configuration->Domains. This is a workaround to make it possible to search for emails in a consistent manner. Users expect to be able to conduct searches using the SMTP address format.

Microsoft's use of X400 addresses was discontinued a long time ago, so it's not an issue today. If MailArchiva encounters an SMTP address, it will be indexed exactly as it appears. Due to  MailArchiva's use of specified local domains in handling X400 addresses, it is important to specify the correct local domains in Configuration->Domains.