Despliegue Preparar Fase de confirmación fallida, No se puede preparar la transacción

Question

Estamos teniendo problemas al intentar publicar o anular la publicación de ciertas páginas y grupos de estructuras después de una migración de SDL Tridion 5.2 a 2011 SP1.

La transacción publicación está fallando en la etapa de despliegue Cometer, y está regresando el siguiente mensaje de error:

Fase: Despliegue Prepare Commit Fase fallado, no puede preparar transacción: tcm: 0-682623-66560 , nulo, nulo

El servicio cd_deployer.exe también se ejecuta con casi el 100% de uso de CPU al mismo tiempo.

también se obtiene la siguiente información en el cd_deployer.log y archivos cd_core.log:

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] 

Extracción de la presentación de los componentes de la página y volver a publicar funciona bien. No funciona el uso de plantillas de componentes diferentes, por lo que parece que el problema está con el componente en alguna parte.

Las páginas, los binarios y los DCP se están publicando en el sistema de archivos. Me preguntaba si el problema estaba relacionado con la publicación de binarios grandes, sin embargo, eliminarlos del componente no hacía ninguna diferencia.

¿Alguien tiene alguna idea de cómo resolver esto?

Saludos cordiales

EDIT: He rastreado esto a una serie de componentes que soy incapaz de publicar o anular la publicación. Al intentar publicar o anular la publicación del componente, la transacción permanece en la etapa de "Implementación de compromiso" durante alrededor de 5 minutos con el servicio cd_deployer maximizando la CPU antes de fallar eventualmente con el mismo mensaje de error.

Si creo una copia idéntica del componente mediante copiar y pegar, esto funciona bien, y va directo a la publicación en un par de segundos sin impacto en la CPU del servidor. ¡Muy extraño!

EDIT 2: Este es un ejemplo de lo que actualmente tenemos en nuestro archivo cd_storage_conf.xml para cada publicación:

<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> 

No hay una correlación de tipos específicos de metadatos.

Answer 1

¿Ha intentado deshacer la publicación y luego republicar las páginas ofensivas? Esto a menudo resuelve el problema para mí. Tengo una teoría que a veces una antigua transacción fallida puede haber bloqueado ciertas filas en el Broker. Des-publicar la página parece liberarlos. Esto realmente no resolverá la causa del problema, pero si funciona debería ayudar a aislar la causa.

Answer 2

Revise su cd_storage_conf - ¿está almacenando todos los metadatos en la misma ubicación? Si no, modifique para que este sea el caso.

Si aún utiliza un cd_broker_conf y permite que el sistema se transforme en cd_storage_conf, sería mejor crear su propio cd_storage_conf, ya que tiene dificultades.

Answer 3

Recuerdo que en el deployer conf, hay una configuración de Fases.Para cada etiqueta de implementación, se define una fase, en cuanto a CUÁNDO se dispara el controlador de implementación: Pre, normal & publicación.

No estoy seguro de cuál es la configuración exacta, pero cuando experimenté el problema cuando estábamos configurando el administrador de archivos.

Además, tuvimos problemas con la implementación/transporte, cuando el directorio de trabajo temporal estaba sobrecargado de datos. borrar la carpeta (por defecto a: c: \ temp o c: \ work) acelerará el proceso.

2 centavos ...