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
Solved! Go to Solution.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
Your query is for performance Or error after Writeback turnoff?
Views
Replies
Total Likes
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..
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies