Diese Konversation wurde aufgrund von Inaktivität geschlossen. Bitte erstellen Sie einen neuen Post.
Level 1
Level 2
Melden Sie sich an, um alle Badges zu sehen
Diese Konversation wurde aufgrund von Inaktivität geschlossen. Bitte erstellen Sie einen neuen Post.
Hi.
I have a problem with DAM assets. They are fired every time when package is deployed to author instance. After deployment, CQ generates rendition, which takes about 3-10minutes. In that time author instance is almost unuseable (pages loads very, very long)
I have aem 6 instance without any hotfixes and using mongoMK.
From time to time, after deployment of my project renditions are generated only for one asset, and also there is an exception in logs:
Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakState0001: Unresolved conflicts in /path/to/jpg/jcr:content
Gelöst! Gehe zu Lösung.
Zugriffe
Antworten
Likes gesamt
Andrew Pikjty wrote...
Mainly about performance. Of course, I don't think so that the error is also positive thing, but this topic is mainly about performance.
I was trying to investigate why this happening, and sometimes, after few deploys, only workflows for few assets has been fired. I'm not sure why. I didn't change anything, I just built project and deployed it to aem6 author instance. I couldn't figure out why those assets weren't generated all the time, and why after few deploys workflows didn't fire up. I checked workflows launcher and the queue was empty.
I also have no idea why generating assets take so much time (this is my main issue), on cq5.6.1 it was quite quick, and during generation, everything was working as usual.
I was thinking about adding some keys to mongo, maybe that's the reason why this takes so much time, but I assumed that this is already done out of the box..
Look at Logs, thread dump, profiler output at time of performance will help.
Zugriffe
Antworten
Likes gesamt
Your query is for performance Or error after Writeback turnoff?
Zugriffe
Antworten
Likes gesamt
Mainly about performance. Of course, I don't think so that the error is also positive thing, but this topic is mainly about performance.
I was trying to investigate why this happening, and sometimes, after few deploys, only workflows for few assets has been fired. I'm not sure why. I didn't change anything, I just built project and deployed it to aem6 author instance. I couldn't figure out why those assets weren't generated all the time, and why after few deploys workflows didn't fire up. I checked workflows launcher and the queue was empty.
I also have no idea why generating assets take so much time (this is my main issue), on cq5.6.1 it was quite quick, and during generation, everything was working as usual.
I was thinking about adding some keys to mongo, maybe that's the reason why this takes so much time, but I assumed that this is already done out of the box..
Zugriffe
Antworten
Likes gesamt
Andrew Pikjty wrote...
Mainly about performance. Of course, I don't think so that the error is also positive thing, but this topic is mainly about performance.
I was trying to investigate why this happening, and sometimes, after few deploys, only workflows for few assets has been fired. I'm not sure why. I didn't change anything, I just built project and deployed it to aem6 author instance. I couldn't figure out why those assets weren't generated all the time, and why after few deploys workflows didn't fire up. I checked workflows launcher and the queue was empty.
I also have no idea why generating assets take so much time (this is my main issue), on cq5.6.1 it was quite quick, and during generation, everything was working as usual.
I was thinking about adding some keys to mongo, maybe that's the reason why this takes so much time, but I assumed that this is already done out of the box..
Look at Logs, thread dump, profiler output at time of performance will help.
Zugriffe
Antworten
Likes gesamt
Nothing special there, logs are clear, there is just information that for some on assets some steps are skipped, but this is normal. A lot of assets are generated after each deploy.
Profiler Results Packages: 33%: com.* 32%: com.scene7.* 32%: com.scene7.is.* 32%: com.scene7.is.scalautil.* 32%: com.scene7.is.scalautil.service 50%: org.* 48%: org.eclipse.* 48%: org.eclipse.jetty.* 32%: org.eclipse.jetty.io.* 32%: org.eclipse.jetty.io.nio 16%: org.eclipse.jetty.server.* 16%: org.eclipse.jetty.server.nio Top 20 stack trace(s) of 399432 ms
this is te profiler results
Zugriffe
Antworten
Likes gesamt
Zugriffe
Likes
Antworten
Zugriffe
Likes
Antworten