Force FSR to publish everything

[samuel_penn]

Hi all,

I'm trying to use the WCM web publishing on Alfresco 2.2, using the File System Receiver to write the web project content to the web server. However, I'm seeing various 'file not found' errors during the publish operation, which is causing it to fail. I believe this is because what is actually at the destination doesn't match what WCM/FSR thinks is there (due to various issues with permissions during initial testing of FSR).

e.g.:

Caused by: java.io.FileNotFoundException: /home/centrom/deployment/depmetadata/default.md/ROOT/survey/Connections/.md.clone (No such file or directory)
‍‍‍

What I would like to do, is to force WCM to re-publish the entire project to the destination site, regardless of what it thinks may or may not be there. Is this possible? Or am I looking at this the wrong way?

Thanks,
Sam.

[pmonks]

This can be achieved by:

1. Shutting down the FSR


2. Deleting the following directories:
   • depdata
   
   
   • deploy
   
   
   • depmetadata
3. Restarting the FSR


4. Redeploying a snapshot

Note that this process will delete everything in the target directory, as well as forcing redeployment for all targets configured in the FSR.

Cheers,
Peter

[samuel_penn]

Thanks for your reply, however that doesn't appear to work for me - I still get exactly the same error. It looks like it's trying to create a file at the bottom of a directory tree, where the tree above it doesn't yet exist. The directory path exists down to default.md/ROOT, but survey and below are missing. Since survey/Connections doesn't exist, the attempt to write to .md.clone fails.

A bigger portion of the error stack is below, which shows that it's trying to create a directory at a non-existing location.

Caused by: org.alfresco.deployment.impl.DeploymentException: Could not write metadata file //home/centrom/deployment/depmetadata/default.md/ROOT/survey/Connections/.md.clone
        at org.alfresco.deployment.impl.server.Target.putDirectory(Target.java:410)
        at org.alfresco.deployment.impl.server.Target.cloneMetaData(Target.java:293)
        at org.alfresco.deployment.impl.server.Deployment.finishWork(Deployment.java:185)
        at org.alfresco.deployment.impl.server.DeploymentReceiverServiceImpl.commit(DeploymentReceiv
erServiceImpl.java:189)
        … 31 more
Caused by: java.io.FileNotFoundException: /home/centrom/deployment/depmetadata/default.md/ROOT/survey/Connections/.md.clone (No such file or directory)
        at java.io.FileOutputStream.open(Native Method)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:70)
        at org.alfresco.deployment.impl.server.Target.putDirectory(Target.java:401)
        … 34 more
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Another strangeness I've noticed, is that the first character of the dep.metadir property in deployment.properties is chopped off, which is why my path above starts with "//home/centrom/…". If I use "/home/centrom", and run the FSR from /home/centrom/deployment, a new depmetadata is created at /home/centrom/deployment/home/centrom/deployment/depmetadatadir, which looks wrong.

Sam.

[pmonks]

Can you post the contents of the deployment.properties file?  Normally this file doesn't need to be touched (assuming the FSR is always started from the folder in which it's installed).

Cheers,
Peter

[samuel_penn]

Okay, since the FSR wasn't guaranteed to be started from the same directory, I'd changed this file to use absolute paths.

I've started with (another) fresh unpackaging of the FSR, and changed the deploy_start.sh to cd to the correct directory, leaving deployment.properties as it is with relative paths. I copied the application-context.xml across from the old installation, and re-run things. It now appears to work.

For reference, the content of the file was:

dep.datadir=/home/centrom/deployment/depdata
dep.logdir=/home/centrom/deployment/deplog
dep.metadatadir=/home/centrom/deployment/depmetadata
dep.rmi.port=44100
‍‍‍‍‍‍

So, not sure if the absolute paths were causing problems. It could have been some bad data hanging around somewhere, but it's not the first time I've installed it from fresh.

Anyway, it works now, thanks.

Sam.

[mrogers]

There are a few known issues with the the creation of the FSR metadata directories in 2.2.0. 
In particular JIRA ETWOTWO-70 which is fixed in 2.2.1.

Anyway I'm glad to hear that you have managed to work around the problem.

[hansraj]

Hi,

Iam using Alfresco Labs3b.
My requirement is like recurring publishing at regular intervals (scheduled publishing).
could anybody please confirm whether we could achive this scheduled publishing in Alfresco?
If so, please guide how to proceed.

Regards,
Hans

[pmonks]

This can be implemented in (at least) the following ways:

1. (2.2+) Via the autodeploy option for deployment targets (possibly in conjunction with scheduled promotion).  See http://wiki.alfresco.com/wiki/Deployment for details.


2. Via the use of an external timer (eg. cron / at) that calls a Web Script at regular intervals, with the Web Script initiating deployment.

Source code for the latter approach is available in the wcm-deployment project on the forge (see http://forge.alfresco.com/projects/wcm-deployment/).  Please note that it was developed against Alfresco v2.1 and may require modification to work on v3.0.

Cheers,
Peter

[hansraj]

Hi,

Thank you for ur reply.
I'll let u know the result.
I'll follow ur advise.