We are experiencing problems when trying to publish or unpublish certain pages and structure groups following a migration to from SDL Tridion 5.2 to 2011 SP1.
The publishing transaction is failing at the Committing Deployment stage, and is returning the following error message:
Phase: Deployment Prepare Commit Phase failed, Unable to prepare transaction: tcm:0-682623-66560, null, null
The cd_deployer.exe service is also running at almost 100% CPU Usage around the same time.
We also get the following information in the cd_deployer.log and cd_core.log files:
2012-05-02 07:32:09,346 ERROR DeployPipelineExecutor - Unable to start processing deployment package with transactionId: tcm:0-682520-66560
2012-05-02 07:36:36,071 ERROR DeployPipelineExecutor - Final attempt in Phase: Deployment Prepare Commit Phase failed for transaction: tcm:0-682526-66560
2012-05-02 07:36:36,071 ERROR DeployPipelineExecutor - Original stacktrace for transaction: tcm:0-682526-66560
com.tridion.deployer.ProcessingException: Unable to prepare transaction: tcm:0-682526-66560, null, null
at com.tridion.deployer.phases.PreCommitPhase.handleFailure(PreCommitPhase.java:120) ~[cd_deployer.jar:na]
at com.tridion.deployer.phases.PreCommitPhase.execute(PreCommitPhase.java:101) ~[cd_deployer.jar:na]
at com.tridion.deployer.phases.DeployPipelineExecutor.runMainExecutePhase(DeployPipelineExecutor.java:186) [cd_deployer.jar:na]
at com.tridion.deployer.phases.DeployPipelineExecutor.doExecute(DeployPipelineExecutor.java:97) [cd_deployer.jar:na]
at com.tridion.deployer.phases.DeployPipelineExecutor.execute(DeployPipelineExecutor.java:61) [cd_deployer.jar:na]
at com.tridion.deployer.TransactionManager.handleDeployPackage(TransactionManager.java:80) [cd_deployer.jar:na]
at com.tridion.deployer.queue.QueueLocationHandler$1.run(QueueLocationHandler.java:176) [cd_deployer.jar:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) [na:1.6.0_30]
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) [na:1.6.0_30]
at java.util.concurrent.FutureTask.run(Unknown Source) [na:1.6.0_30]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [na:1.6.0_30]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [na:1.6.0_30]
at java.lang.Thread.run(Unknown Source) [na:1.6.0_30]
Removing the component presentation from the page and republishing works OK. Using different component templates doesn't work, so the issue appears to be with the component somewhere.
Pages, binaries and DCPs are all being published to the file system. I did wonder if the problem related to publishing large binaries, however removing them from the component didn't make any difference.
Does anyone have any ideas how to resolve this?
Kind regards
EDIT: I have now tracked this down to a number of components which I am unable to publish or unpublish. When attempting to publish or unpublish the component, the transaction remains at the "Committing Deployment" stage for around 5 minutes with the cd_deployer service maxing out the CPU before eventually failing with the same error message.
If I create an identical copy of the component via copy and paste, this works fine, and goes straight through publishing in a couple of seconds with no impact on the server's CPU. Very strange!
EDIT 2: This is an example of what we currently have in our cd_storage_conf.xml file for each publication:
<Storage Type="filesystem" Class="com.tridion.storage.filesystem.FSDAOFactory" Id="21_content" defaultFilesystem="false">
<Root Path="D:/WebSites/live/Website/wwwroot/" />
</Storage>
<Storage Type="filesystem" Class="com.tridion.storage.filesystem.FSDAOFactory" Id="21_data" defaultFilesystem="true" defaultStorage="true">
<Root Path="D:/WebSites/live/Website/Data" />
</Storage>
<Publication Id="21" defaultStorageId="21_data" cached="false">
<Item typeMapping="Page" cached="false" storageId="21_content"/>
<Item typeMapping="Binary" storageId="21_content" cached="false"/>
<Item typeMapping="ComponentPresentation" storageId="21_data"/>
</Publication>
There isn't a specific type mapping for metadata.
Have you tried un-publishing then republishing the offending pages? This often solves the problem for me. I have a theory that sometimes an old failed transaction may have locked certain rows in the Broker. Un-publishing the page seems to free them up. This won't really solve the cause of the problem, but if it works it should help isolate the cause.
Check your cd_storage_conf - are you storing all metadata into the same location? If not, modify so this is the case.
If you are still using a cd_broker_conf and allowing the system to transform to the cd_storage_conf, it would be better to create your own cd_storage_conf, since you are encountering difficulties.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With