Overview

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. The error 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.

Prerequisites

• Must have Liquid Content enabled.

Diagnosis

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.

The stack trace shows the following in the Log files in the Portals/_default/Logs folder

[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)
   at DotNetNuke.Services.Search.Internals.LuceneControllerImpl.get_Writer()
   --- End of inner exception stack trace ---
   at DotNetNuke.Services.Search.Internals.LuceneControllerImpl.get_Writer()
   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.

Solution

This issue has been fixed in Evoq 9.2.1, you should be able to upgrade to the newest version of Evoq to resolve this issue.

If you are not in the position to upgrade you can perform the following workarounds below:

• For a customer on a single server:

  Remove the write.lock file from your /app_data/search folder, 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.

Testing

To test that Liquid content is now updating properly:

1. Go to Content > Content Library > Go to a Content Item > Update a content item such as a text field.
2. Go to any page where the visualizer is located and see if the changes have been made.

If the content is still not updated, review the Log files in the Portals/_default/Logs folder.