We are seeing deadlocks in SQL seemingly caused by ChangeNotificationHeartBeat which in turn calls ChangeNotificationAccessConnectionWorker which is updating values in tblChangeNotificationConnection. This race condition is being triggered seemingly in a load balanced environment as both servers are triggering the ChangeNotificationHeartBeat procedure every 5 seconds and sometimes overlap.
Can someone confirm if this is a known issue and/or there is a work around or if this is caused by the misconfiguration of a load balanced environment and point me at the appropriate documentation. From re-reading http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-CMS/8/Deployment/Deployment-scenarios/Deploying-to-Windows-Servers/ I cannot see a step that would prevent this issue.
Whilst we are running a commerce setup this is posting here as my understanding is that this notification system is part of the wider CMS framework
We are experiencing the exact same thing.
We also have a load balanced environment, and can reproduce it by setting the "Maximum Worker Processes" to more than 1 (simulate load balanced environment) in our IIS applicataion pool.
(We have modified our local host files, and set up an IIS site with application pool on our local developer machines)
We have not found a solution, but are talking to Episerver to figure this out.
Do you have any steps on how to reproduce this maybe with the Quicksilver project?
If anyone have experinced this it would be cool if you would reply to this so we can figure this out! :)
For anyone who wants to reproduce this issue (I also send this EPiServer and will post an update once I get an answer)
I managed to recreate the problem in Episervers Quicksilver project.
Here are the steps I did to recreate the problem:
Then we must setup the project in IIS (Internet Information Services):
Now we must start multiple instances of the site:
Now we need to capture the deadlocks in the SQL Profiler:
Now that the profiler is running is time to wait.
For me it took some time (30 minutes until the first deadlock happened)
Disable the scheduler on other servers from web.config, make sure there is only one server running the schedule job.