Optimizing the Tagger.config file settings
The Tagger.config file contains advanced settings that should only be updated from guidance of our support team. The file is located in the following location: “{installation path}\config\Tagger.config”.
If a setting in the config file is updated, the Tagging service must be restarted by going to Settings > Advanced and turn the service off and on again.
Some of the common settings available in the Tagger.config file are described below.
| Setting | Description |
|---|---|
| debugLogging | Set this to true to help debug problematic errors. The debug log files will be saved to “{installation path}\live\log\{Job ID}\{JobID}[{RunID}]_debug.txt” |
| checkServiceEvery | This interval to periodically check the status of the Tagging service. If the status of a job is set to as running even though the service has stopped, it will be put into an error state. The default is to check the service every 60 minutes. |
| enumerationMaxParallelism | When enumerating documents from large SharePoint libraries, Nutrient Document Searchability Tagging partitions the retrieval so that the documents are retrieved in chunks. These chunks can be retrieved in parallel, which can significantly speed up enumeration. This setting is used to control the maximum number of chunks that can be retrieved at once. Note, however, that the maximum value will be limited to the maximum cores your license permits. |
| skipCheckedOutDocument | Set this to true to skip checked-out documents from being processed. |
| retainApprovalStatus | When documents are processed in a SharePoint library which requires Content Approval, it will set them to ‘Pending’ after processing. Set this setting to “true” to retain the original Approval Status after the documents have been processed. |
| downloadAndUploadRetries and sharePointRequestRetries | Occasionally, there might be some intermittent network problems or unusual extreme load on the SharePoint server which can cause problems when processing SharePoint document libraries. To cope with this, retry mechanisms have been implemented for different scenarios that will retry performing a particular task in the event of such problems (e.g. timeouts). There are 2 SharePoint retry settings available: downloadAndUploadRetries- used when downloading and uploading documents fail- sharePointRequestRetries- used when executing SharePoint queries fail. The number of retries and the amount of time to wait between retries can be controlled through the respective config settings. The value needs to be entered in the format “x,y”, where x is the number of retries and y is the time (in milliseconds) to wait before the first retry. For subsequent retries, the time to wait will be twice the previous wait time. |
| databaseRetries | Sometimes, if a job is set to process using multiple cores, Tagging may encounter problems when it tries to update the database due to it being ‘locked’ because of concurrent updates. To overcome this problem, a retry mechanism has been implemented that will retry updating the database if it fails the first time. The number of retries and the amount of time to wait between retries can be controlled through this setting. The value needs to be entered in the format “x,y”, where x is the number of retries and y is the amount of time in milliseconds to wait for each retry. |
| formsAuthCookieRefreshInterval | The amount of time before refreshing forms based authentication cookies. The default is current set to 900,000 milliseconds (15 minutes). |