topic Re: Lock problem while deploying in Alfresco Archive

Lock problem while deploying

jakub_hozak — Mon, 14 Apr 2008 17:02:43 GMT

Greetings!I've got a problem when deploying the WCM project. There is a locked file/node '__localhost deployment report.txt'which blocks the process. Everytime I try to deploy some content from the staging sandbox to production, onlyan error message appears about the locked file and nothing happens.

Re: Lock problem while deploying

kvc — Sat, 19 Apr 2008 16:38:02 GMT

Jakub:

We've not seen this before … at least, there's nothing yet filed in JIRA.

If you are on subscription, can you file a support ticket so that we can get an Engineering to look into? If not, please do raise the issue in JIRA so that we can track.

Kevin

Re: Lock problem while deploying

tommorris — Mon, 21 Apr 2008 08:22:16 GMT

We get this file appearing the rep too.
It doesn't cause us any locking problems though.

Re: Lock problem while deploying

kvc — Mon, 21 Apr 2008 21:15:17 GMT

In pre-2.2 release, we maintained only one deployment report for each Staging area, which was overwritten upon each subsequent deployment.

Now, one reason why you may have this locking error is that another user may have concurrently issued a deployment request, and the first deployment
is still concluding and writing back to the deployment report file. Or, a previous deployment was interrupted writing back to the report file, and it
never released it's lock (on a side note, users can concurrently deploy; one the receiving side, however, all deployment requests stack up and serialize -
necessarily - so that we can guarantee consistent snapshots that corresond with Staging).

This should all go away with 2.2E, however - even in the case of the interrupted deployment. In 2.2E, we maintained a configurable number of
deployment reports per Staging sandbox; the default is 10,000. In this case, no deployment should ever attempt to write to the same file - and
so even if there's a lingering lock, that shouldn't be an issue for any subsequent request.

If also means you have some great audit trails. You can read more on the Deployment page on the wiki. This 2.2E feature will be rolled into the
next 2.9 Community build.

Kevin