Lock.msg already exists

(0) Share

Report

Posted on by Arsenico

I am getting the error message below from time to time when submitting a form. Everything seems to be saved and sent to CRM, but the user sees this error message and can't continue.

Error message:

The file 'D:\home\site\wwwroot\App_Data\Adxstudio.Xrm.AspNet.PortalBus\CacheInvalidationPortalBusMessage\c754a014629dca2ebbb48fbd83c84787b844fd1692ade17e488cf6b8033a8ecc\20161118124310606.lock.msg' already exists.

Anyone knows what caused this and how to resolve it ?

*This post is locked for comments

I have the same question (0)

All responses (15)

Answers (1)

Suggested answer

Community Member on at

Like (0)

Report

Hi Arsenico,

Is that what you are going through?

community.adxstudio.com/.../59f50227-0f2f-e611-9403-000d3a10c9a8

Was this reply helpful? Yes No
Arsenico on at

Like (0)

Report

Yes, it is. Running on Azure connected to CRM Online. It is indeed the same issue as mentioned on the Adxstudio forum. But the answer suggested there (IaaS) is no longer an option.

Was this reply helpful? Yes No
Verified answer

Colin V on at

Like (0)

Report

Azure Cloud Service are still available and will not have the same cache invalidation issue as the Azure Web App. If you do use a cloud service ensure you setup your deployment as the following article outlines.

community.adxstudio.com/.../cache-invalidation-using-windows-azure-inter-role

The other way to solve this without switching to IaaS/Cloud Services is to run only a single portal instance. This issue only appears when running multiple instances that then try and write to the same filename concurrently.

Was this reply helpful? Yes No
Arsenico on at

Like (0)

Report

I managed to deploy the solution to Azure Cloud Service and have applied the setup you provided. Unfortunately the performance of the cloud service is about 25 times slower than the web app. When checking trace.axd it seems like the LookupAndInsert step takes much longer to process. Any suggestions on how to tweak this setting ?

When performance is so low we cannot go and test the locking issue.

About running the single portal instance. How are multiple instances setup ? Because as far as I know only one instance is running on the web app.

Was this reply helpful? Yes No
Craig P. Fleming 950 on at

Like (0)

Report

This is a known issue in version 7. Presumably you are using a webapp and the only know workaround at this time for webapp is to restrict it to a single instance and replace the PortalBusOrganizationServiceCache with the ContentMapOrganizationServiceCache in your web.config. My team has been tracking this issue for awhile now and are hopeful for it to be addressed in the next release.

Was this reply helpful? Yes No
Arsenico on at

Like (0)

Report

The reason the Cloud service was so slow was because of my Intellitrace was fully enabled. After disabling and redeploying the portal runs fine on the Cloud service. Any other pitfalls using Cloud service you guys know about ?

Was this reply helpful? Yes No
G. E. Goodwin on at

Like (0)

Report

Craig,

For v7 Portals running in a Web App environment, is it possible to enable Local Cache in the web app and configure Service Bus or some other form of distributed cache invalidation to prevent the locking bug?

Was this reply helpful? Yes No
Craig P. Fleming 950 on at

Like (0)

Report

I don't think it would be practical to try and plumb everything but honestly I haven't really given SB much if any thought. I will give it some thought and respond to the thread if something comes of it. The single instance is the way to go right now and scale upward versus horizontal. I am hopeful that this will be addressed soon as we've provide details on the precise fix that is required. Unfortunately because of where it exists in the MS code it is not something that is easy to correct with custom code, believe me we've tried:).

Was this reply helpful? Yes No
G. E. Goodwin on at

Like (0)

Report

What has us concerned is that we are experiencing the cache invalidation locks in the web app environment even when running only one instance. We're running an S2 with 2 cores and 3.5 GB RAM, Portals is the only app running and we're in beta with very low user load. Unfortunately, we're stuck in beta until this bug gets resolved because we can't risking moving to production with such a prevalent, random bug occurring.

Was this reply helpful? Yes No