topic Re: FSR non-atomic copy race condition in Alfresco Archive

FSR non-atomic copy race condition

devmonkey — Tue, 28 Apr 2009 14:06:25 GMT

Hi,When we publish file overwrites through the FSR at the same time as the target directory is being read by the webserver it is possible for the webserver to miss the file or read a partially written file. This is because the FSR performs the following steps to overwrite a file:1. Move oldFile to o

Re: FSR non-atomic copy race condition

mrogers — Tue, 28 Apr 2009 16:19:52 GMT

Peter Monks blogged on this subject a while back. http://blogs.alfresco.com/wp/pmonks And your solution is one of the options for OS's that have symbolic links.

Although there may be a small theoretical problem, the vast majority of people find that the effort of fixing this particular
problem is not worth it. And you will also find that your OS affects the file locking behaviour, so you may find that the problem
is even smaller than you think.

Another idea is to use a virtual file system and Peter and I have been kickingaround the idea of using CouchDB for deployment.

Re: FSR non-atomic copy race condition

devmonkey — Tue, 28 Apr 2009 16:35:14 GMT

Unfortunately this bug makes the FSR unusable under our normal load conditions since our request rates are relatively high.

I've decided the two directories with a link swap is not the correct approach for us. I'll just patch the FSR to do an atomic rename/overwrite after the new file is flushed to a temporary namespace, which looking at the src may have been the original intention however it is done the other way round. This will work on linux but not windows.

Note we are not concerned with the atomicity of a deployment wrt to the reader process, just the atomicity of the overwrite of individual files within that deployment.

Can anyone point me to the 2.1.0 src for the FSR?

Cheers, Joe.