Prev: E-mail Notifications
Next: Provisioning failed: File or arguments not valid for site template 'OSRV'.
From: jj_in_atlanta on 2 Aug 2007 14:12 I'm getting errors in my trace logs (and in the application event log) about a concurrency exception. It happens every 5 minutes and has been doing so for quite awhile it seems. There is a critical exception: The Execute method of job definition Microsoft.SharePoint.Search.Administration.SPSearchJobDefinition(ID [guid]) threw an exception but the trace log entry with the most useful info is this one: OWSTIMER.EXE (0x00EC) 0x0BE0 Windows SharePoint Services Topology 75bd High UpdatedConcurrencyException: The object SPSearchDataAccessServiceInstance Parent=SPServer Name=EAVDEVWSS01 was updated by another user. Determine if these changes will conflict, resolve any differences, and reapply the second change. This error may also indicate a programming error caused by obtaining two copies of the same object in a single thread. Previous update information: User: DOMAIN\account1 Process:OWSTIMER Machine:EAVDEVWSS01 Time:May 15, 2007 04:05:00.0000 Current update information: User: DOMAIN\account1 Process:OWSTIMER Machine:EAVDEVWSS01 Time:August 02, 2007 01:50:00.2266 Any idea how I can clear the concurrency issue?
From: Wei Lu [MSFT] on 2 Aug 2007 22:38 Hello JJ, I found that this issue is caused by a disaster recovery. The file-system cache on the front end is newer than the contents of the configuration database. After a disaster recovery, it may be necessary to manually clear the file system cache on the local machine. Resolution ============================= Clear the file system cache on all servers in the farm running the timer service manually. To do this, stop the timer service, delete (or move) the contents of the folder at %ALLUSERSPROFILE% \Application Data\Microsoft\SharePoint\Config\<someGuid> Then, simply restart the timer service. The cache will be rebuilt and the issue should disappear. This should be done on every machine in the farm running the timer service Hope this helps! Sincerely, Wei Lu Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
From: jj_in_atlanta on 3 Aug 2007 09:18
That fixed it - thank you very much for your assistance. "Wei Lu [MSFT]" wrote: > Hello JJ, > > I found that this issue is caused by a disaster recovery. The file-system > cache on the front end is newer than the contents of the configuration > database. After a disaster recovery, it may be necessary to manually clear > the file system cache on the local machine. > > Resolution > ============================= > Clear the file system cache on all servers in the farm running the timer > service manually. To do this, stop the timer service, delete (or move) the > contents of the folder at > %ALLUSERSPROFILE% \Application Data\Microsoft\SharePoint\Config\<someGuid> > > Then, simply restart the timer service. The cache will be rebuilt and the > issue should disappear. This should be done on every machine in the farm > running the timer service > > Hope this helps! > > Sincerely, > > Wei Lu > Microsoft Online Community Support > > ================================================== > > When responding to posts, please "Reply to Group" via your newsreader so > that others may learn and benefit from your issue. > > ================================================== > This posting is provided "AS IS" with no warranties, and confers no rights |