About Index Resilience
Example: Index files may be locked while they are scanned by an anti-virus software (which by the way is not a good practice, see CES and Anti-Virus Software) or defragmented by a Windows process. A non-fatal error occurs when a locked file needs to be modified for a transaction. Other attempts to process the transaction will be made on the next commits during which the file will most likely no longer be locked, allowing the transaction to be committed without interrupting the CES Service.
When a non-fatal error occurs during the application of a transaction, rather than immediately stopping the CES service, only a mini core dump file is created ([CES_Path]\CoreDumps\CESService7_nnnn_yymmdd_hhmmss_mini.dmp) thus only shortly pausing the index processes as well as saving disk space and processing resources.
A few attempts to perform the process that caused the error are made:
-
When the error condition no longer exist, the operation goes through and the CES Service is not interrupted.
-
When the error condition persists, the CES process is stopped and a core dump file created ([CES_Path]\CoreDumps\CESService7_nnnn_yymmdd_hhmmss_full.dmp). The CES Service must be immediately restarted by the Windows Service Control Manager (default configuration).
When a non-fatal error is detected, the index resilience feature writes the following error messages in the CES Console and in the logs:
-
Unexpected non-fatal exception X in thread Y
-
An unexpected exception occurred while processing a transaction. The transaction processing will restart X more time(s) with the next index commit(s).