The purpose of this article is to assist customers with an issue that occurs when updates are made to a Liquid Content item, and the content is not reflected in the visualizer. It may take multiple update attempts for the content to be updated.
The stack trace shows the following:
[ERROR] DotNetNuke.Services.Exceptions.Exceptions - DotNetNuke.Services.Exceptions.SearchException: Unable to create Lucene writer (lock file is in use). Please recycle AppPool in IIS to release lock. ---> System.IO.IOException: The process cannot access the file 'C:\DNN\App_Data\Search\write.lock' because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.InternalDelete(String path, Boolean checkHost)
--- End of inner exception stack trace ---
at DotNetNuke.Services.Search.Internals.LuceneControllerImpl.Delete(Query query)
at DotNetNuke.Services.Search.Internals.InternalSearchControllerImpl.DeleteSearchDocumentInternal(SearchDocument searchDocument, Boolean autoCommit)
at Evoq.StructuredContent.Visualizer.Components.VisualizerSearchManager.DeleteSearchDocument(Int32 moduleId, Int32 portalId, Guid contentItemId)
at Evoq.StructuredContent.Visualizer.Components.VisualizerSearchManager.DeleteSearchDocuments(Int32 portalId, Relationship relationship)
at Evoq.StructuredContent.Visualizer.Components.Integrations.StructuredContentListener.ClearRenderForModules(StructuredContentChangeNotification notification, IEnumerable`1 relationships)
at Evoq.StructuredContent.Visualizer.Components.Integrations.StructuredContentListener.Notify(StructuredContentChangeNotification notification)
at Evoq.StructuredContent.Library.Components.Notifier.StructuredContentNotifierService.Notify(StructuredContentChangeNotification notification)
at Evoq.StructuredContent.Library.Services.StructuredContentCacheController.Notify(StructuredContentChangeNotification changeInformation)
at lambda_method(Closure , Object , Object )
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass10.<GetExecutor>b__9(Object instance, Object methodParameters)
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken cancellationToken)
The error message on the first line is key to identifying and resolving the issue (emphasis added):
Unable to create Lucene writer (lock file is in use). Please recycle AppPool in IIS to release lock. ---> System.IO.IOException: The process cannot access the file
C:\DNN\App_Data\Search\write.lock because it is being used by another process.
There currently is a bug where the Liquid Content update function is called whenever an update is performed on the Content Library, and it uses the Lucene Search to delete search documents. The file lock error occurs when a webhead does not have the rights over the write.lock file and attempts to call notify(). The result is that the content is not updated on the site; it is updated on the MicroServices, but the content on pages remains unchanged.
For a customer on a single server:
Remove the write.lock file from your
/app_data/searchfolder, as it may have been orphaned from another site. If you cannot remove the write.lock file, please recycle the application pool a few times in IIS to remove the file lock, and then try the deletion again.
For a customer on a web farm:
Confirm that the File Crawler is only running in one webhead to avoid issues with the mutex file, and confirm that it is completing without errors. Additionally, only run the file crawler after hours to ensure that the write.lock mutex file is not present during business hours. This way, users should be able to modify the Visualizer content without any errors.
As a final workaround, you can also attempt to delete and then recreate the affected visualizer module to flush out the cache.