FSR non-atomic copy race condition

[devmonkey]

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 oldFile.alf
2. Stream stagedFile into newFile.
3. Flush output stream

So between 1 and 2 the file does not exist wrt to any reading process. And during the stream copy the file is only partially written.

We were thinking of using two target directories, t1and t2, one for the FSR to update, the other a readonly copy for the webserver to read. Two symlinks tw and tfsr that would point to the directory (either t1 or t2) that the webserver should read from and the fsr should write to respectively.  A script would have to fired post commit that did the following:
1. swap tw and tfsr
2. copy tw diffs into tfsr, bringing tfsr uptodate for the next publication

How do others work around this problem?

Cheers, Joe.

[mrogers]

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.

[devmonkey]

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.