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
Awesome news! We're going to upgrade and give it a try. Thanks for your help with this.
We noticed that it was absent in the release notes too which was disappointing, but after inspecting the dll just now, I see that the code appears to have been modified from using a datetime object to a guid, which should alleviate the problem.
We received word from Microsoft support yesterday that the cache invalidation lock bug was fixed in v7.0.0.0023. Have you heard whether this is true? It is not mentioned in the release notes.
Craig,
I wanted to confirm that swapping out the PortalBusOrganizationServiceCache has eliminated the cache invalidation error for us running on a single instance in the Web App environment.
Is there any guidance you can give from experience regarding how much load a single instance web app running Portals can handle? I know this is an impossible question to definitively answer because of the countless variables involved, but we have zero context for how to plan for infrastructure needs because this will be the first production instance of Portals we've run. And we don't want the launch of our first instance to be a failure. We are currently running an S2 with 2 cores and 3.5 GB RAM. The only scale up option is a 4 core 7 GB RAM instance. We'll have a user base of 1,000 users of which we could have 300-400 max concurrent users. The call we have to make is do we wait to launch production until a fix is released, or do we launch on a single instance and hope it will be enough to handle our user load. It would be so much easier if the fix, which you've already mentioned has been identified, would be released by the Portals team.
We've swapped out the setting now and are testing. I'll post here if we run into problems.
Have you made the web.config changes I indicated, swapping out the PortalBusOrganizationServiceCache?
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.
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:).
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?
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 ?
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 291,240 Super User 2024 Season 2
Martin Dráb 230,149 Most Valuable Professional
nmaenpaa 101,156