3

We are having some issues trying to publish several components. For example, If we send 10 components, some of them stay in "Waiting for deployment" state and finally return "Failed", and the others get "Success" status at the first time. If we re-send failed component we get the same result, some of then return "Success" status and the others stay in "Waiting for deployment".

We have this problem in Web 8.5.

We change the logs level to "ALL" and this is the result:

2018-06-04 13:09:34,955 TRACE CommandQueuePoller - Nothing to dequeue on: ContentQueue 2018-06-04 13:09:35,005 WARN TridionTransactionalExecutableStep - Rollback transaction due to error. ExecutionId: tcm:0-4877215-66560 error: org.hibernate.exception.LockAcquisitionException: could not execute statement 2018-06-04 13:09:35,005 TRACE TridionTransactionalExecutableStep - TridionPreCommitStep exception logged only for debug purposes: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:147) at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:155) at org.hibernate.query.internal.AbstractProducedQuery.list(AbstractProducedQuery.java:1407) at org.hibernate.Query.getResultList(Query.java:417) at com.tridion.storage.persistence.JPABaseDAO.executeQueryListResult(JPABaseDAO.java:302) at com.tridion.storage.persistence.JPABaseDAO.executeQueryListResult(JPABaseDAO.java:270) at com.tridion.storage.persistence.JPABaseDAO.executeQueryListResult(JPABaseDAO.java:241) at com.tridion.storage.persistence.JPABaseDAO.executeQuerySingleResult(JPABaseDAO.java:220) at com.tridion.storage.persistence.JPAItemDAO.findByPrimaryKey(JPAItemDAO.java:204) at com.tridion.storage.persistence.JPAItemDAO.findByPrimaryKey(JPAItemDAO.java:193) at com.tridion.storage.deploy.workers.ComponentWorker.doDeploy(ComponentWorker.java:41) at com.tridion.deployer.model.transaction.TransactionLogItemWorker.doWork(TransactionLogItemWorker.java:42) at com.sdl.delivery.deployer.steps.TridionPreCommitStep.process(TridionPreCommitStep.java:67) at com.sdl.delivery.deployer.engine.pipeline.actor.StepActor.execute(StepActor.scala:72) at com.sdl.delivery.deployer.engine.pipeline.actor.StepActor.com$sdl$delivery$deployer$engine$pipeline$actor$StepActor$$processStep(StepActor.scala:57) at com.sdl.delivery.deployer.engine.pipeline.actor.StepActor$$anonfun$receive$1.applyOrElse(StepActor.scala:40) at akka.actor.Actor$class.aroundReceive(Actor.scala:480) at com.sdl.delivery.deployer.engine.pipeline.actor.StepActor.aroundReceive(StepActor.scala:26) at akka.actor.ActorCell.receiveMessage(ActorCell.scala:526) at akka.actor.ActorCell.invoke(ActorCell.scala:495) at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257) at akka.dispatch.Mailbox.run(Mailbox.scala:224) at akka.dispatch.Mailbox.exec(Mailbox.scala:234) at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260) at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339) at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107) Caused by: org.hibernate.exception.LockAcquisitionException: could not execute statement at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:123) at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:42) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:97) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:207) at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:45) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3119) at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2998) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3378) at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:145) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:582) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:456) at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:337) at org.hibernate.event.internal.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:50) at org.hibernate.internal.SessionImpl.autoFlushIfRequired(SessionImpl.java:1368) at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1453) at org.hibernate.query.internal.AbstractProducedQuery.doList(AbstractProducedQuery.java:1426) at org.hibernate.query.internal.AbstractProducedQuery.list(AbstractProducedQuery.java:1398) ... 24 common frames omitted Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Transaction (Process ID 61) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:217) at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1655) at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doExecutePreparedStatement(SQLServerPreparedStatement.java:440) at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement$PrepStmtExecCmd.doExecute(SQLServerPreparedStatement.java:385) at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:7505) at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:2444) at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:191) at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:166) at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeUpdate(SQLServerPreparedStatement.java:328) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:204) ... 37 common frames omitted 2018-06-04 13:09:35,009 WARN StepActor - Step 'TridionPreCommitStep' for 'tcm:0-4877215-66560' failed with message: com.sdl.delivery.deployer.api.processing.exception.ProcessingException: Unable to prepare transaction: tcm:0-4877215-66560

Anybody can help us?

Thanks a lot.

Improve this question
4
  • Probably the same issue as with specific tech stacks on Tridion 2013. I suggest you look through similar issues answered in this forum. I recall we had something like this in the past on a Websphere app server, but I can’t remember if it was Websphere related in the end or if it was database. What do you run for the app server and what database? Please update your question with details around versions, as well as what efforts you put in to try and resolve this.
    – Nickoli Roussakov
    Jun 6, 2018 at 12:21
  • Thanks for your reply. We are using SQL Server and Tomcat 8. We are trying to stop publisher service and restart again to check if the package waiting in incoming folder could be procesing by deployer but it's not like that. In the other hand, we also change the cd_deployer.conf to include RetriesInterval attribute and lowering workers attribute from 20 to 10: <Location Path="/var/app/tridion/incomingFTP" WindowSize="40" Workers="10" Cleanup="true" Interval="2s" **RetriesInterval**="10s"/>
    – Sergio G
    Jun 6, 2018 at 13:43
  • I recall there are a number of hotfixes available for the microservices that deal with issues of deadlocks when doing large publishes. Did you apply these hotfixes ?
    – Harald Hoffelinck
    Jun 6, 2018 at 17:02
  • Thanks for your reply. We didn'y apllied these hotfixes because this also happens when we send 5 o 10 components to publish, (also with 30 o 40) but we are thinking that the problem was another. In this case we saw this link in sdl documentation link
    – Sergio G
    Jun 7, 2018 at 9:03

1 Answer 1

Reset to default
1

Seems like it causes the number of deployer/publisher processes specified in the Tridion Snap-in exceeds the number of CPU cores.

Update Publisher Settings, deployer and rendering threads to be less than or equal to the number of processors available.

Please remember that as you have 4 publishers for 1 deployer, this one can only accept a certain number of threads coming from the publishers.

AFAIK - There is a hotfix for the SQL deadlock error for deployer service (CD_8.5.0.5099.zip) - Please double with SDL Support.

I hope it helps

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.