Error: “Could not obtain an exclusive lock to copy the WRC version.”


Webtrends Analytics 8.x
Webtrends Analytics 9.x


The following error message displays in the status messages after a failed analysis:

Could not obtain an exclusive lock: Could not obtain an exclusive lock to copy the WRC version.


The cause of this issue is that the analysis engine, or more specifically, the Analysis Sync Utility (ASU) on that engine is unable to obtain a lock on the engine folder that is located in the storageconfig repository. During an analysis, the ASU performs a check comparing the version of the engine folder in use in its local modulesanalysis directory to the one in the storageconfig repository. If they match, the analysis will continue. If not, it will attempt to download the more up-to-date copy from the storage repository. If the engine folder doesn’t exist under modulesanalysis, it will trigger a download of the engine folder from the storage repository. If the ASU’s attempt to verify the folders are in sync, or the attempt to download the engine folder is blocked for any reason, this error message will result.

There are some valid reasons why an engine folder will not be present in the modules cache. For example, on installation of a new analysis engine, the modules cache will be empty, and will be created on the first analysis. Another cause is if the folder, or parts of it, was deleted as part of the troubleshooting process.

Reasons for the version check to fail include network latency, file contention (too many other engines are currently copying or checking version), the storage repository becoming unavailable or corruption of the system database and/or system files.

The most visible effect of this error is that all analysis jobs will fail on the node in question until the check to see if both folders are in sync is successful, or the copy of the engine folder can complete. This error may manifest after a maintenance event when the analysis engines are all polling for new folder versions.

The more engines in the distributed environment, the greater the likelihood this may occur. If you have consistent connectivity to the storage repository, this error will clear itself up the next time an analysis job tries to run.

If you wish to mitigate the risk of seeing this error, after an upgrade or similar maintenance event, bring the engines online one by one and let each start an analysis. This gives each engine a chance to copy the folder before the next one begins polling for it. Alternately, you can manually copy the contents of the storageengine repository into the modulesengine folder on a node that continues to fail.