Le chargement PDF entraîne le plantage du processus Java d'AEM

Rechercher

Dernière mise à jour le 1 mai 2021

Problème

Lorsque vous chargez certains fichiers PDF vers AEM, l'utilisation de la mémoire du système d'exploitation par la JVM est trop élevée. Le processus Java se bloque ou plante. Sous Linux, le système d’exploitation élimine le processus Java.

Les vidages de fils d'exécution affichent des fils similaires qui entraînent une utilisation élevée de l'unité centrale.

"JobHandler: /etc/workflow/instances/server0/2017-03-08_4/update_asset_6:/content/dam/test.pdf/jcr:content/renditions/original" #3270 daemon prio=1 os_prio=-2 tid=0x0000000020802000 nid=0xc7d0 runnable [0x00000000396be000]
java.lang.Thread.State: RUNNABLE
at sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method)
at sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:156)
at sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:155)
locked <0x00000000f55ab218> (a sun.java2d.cmm.lcms.LCMSTransform)
at sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:629)
at java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:182)
at com.adobe.internal.pdftoolkit.color.ColorManager.convertICCToDeviceRGB(ColorManager.java:167)
at com.adobe.internal.pdftoolkit.pdf.graphics.impl.ColorSpaceCacheImpl.toRGB(ColorSpaceCacheImpl.java:175)
at com.adobe.internal.pdftoolkit.services.pdfParser.ParserUtils.preProcessAxialShading(ParserUtils.java:264)
at com.adobe.internal.pdftoolkit.services.pdfParser.ContentStreamParser.applyShading(ContentStreamParser.java:1713)
at com.adobe.internal.pdftoolkit.services.pdfParser.ContentStreamParser.sh(ContentStreamParser.java:1672)
at com.adobe.internal.pdftoolkit.pdf.content.processor.ShadingPatternOperator.process(ContentOperators.java:790)
at com.adobe.internal.pdftoolkit.pdf.content.processor.ContentStreamProcessor.process(ContentStreamProcessor.java:103)
at com.adobe.internal.pdftoolkit.services.pdfParser.PDFContentItemsList$PDFContentItemsListIterator.processObjects(PDFContentItemsList.java:176)
at com.adobe.internal.pdftoolkit.services.pdfParser.PDFContentItemsList$PDFContentItemsListIterator.hasNext(PDFContentItemsList.java:127)
at com.adobe.internal.pdftoolkit.services.rasterizer.impl.RasterDocument.createPage(RasterDocument.java:129)
at com.adobe.internal.pdftoolkit.services.rasterizer.impl.PDFToRasterConverter.toBufferedImage(PDFToRasterConverter.java:127)
at com.adobe.internal.pdftoolkit.services.rasterizer.PageRasterizer.next(PageRasterizer.java:98)
at com.day.cq.dam.handler.standard.pdf.PdfHandler.getImage(PdfHandler.java:592)
at com.day.cq.dam.handler.standard.pdf.PdfHandler.getImage(PdfHandler.java:555)
at com.day.cq.dam.core.process.CreatePdfPreviewProcess.execute(CreatePdfPreviewProcess.java:109)
at com.day.cq.workflow.compatibility.CQWorkflowProcessRunner.execute(CQWorkflowProcessRunner.java:93)
at com.adobe.granite.workflow.core.job.HandlerBase.executeProcess(HandlerBase.java:189)
at com.adobe.granite.workflow.core.job.JobHandler.process(JobHandler.java:244)
at org.apache.sling.event.impl.jobs.JobConsumerManager$JobConsumerWrapper.process(JobConsumerManager.java:500)
at org.apache.sling.event.impl.jobs.queues.JobQueueImpl.startJob(JobQueueImpl.java:291)
locked <0x00000000c91531e0> (a org.apache.sling.event.impl.jobs.queues.JobExecutionContextImpl)
at org.apache.sling.event.impl.jobs.queues.JobQueueImpl.access$100(JobQueueImpl.java:58)
at org.apache.sling.event.impl.jobs.queues.JobQueueImpl$1.run(JobQueueImpl.java:227)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

Environnement

AEM 6.2 sous Oracle Java 1.8

Résolution

A. Effacer les tâches sling du workflow de ressources de mise à jour

Allez à http://host:port/crx/de/index.jsp et connectez-vous en tant qu'utilisateur admin.

Accédez à ce chemin où {slingid} est l’identifiant sling de l’instance AEM.

/var/eventing/jobs/assigned/{slingid}/com.adobe.granite.workflow.job.etc.workflow.models.dam.update_asset.jcr_content.model

Cliquez avec le bouton droit de la souris et supprimez le nœud com.adobe.granite.workflow.job.etc.workflow.models.dam.update_asset.jcr_content.model
Enregistrer
Redémarrez AEM.

Cette opération supprime toutes les tâches sling actives pour les fichiers PDF qui entraînent un plantage dans AEM.

B. Installation de l'outil de ligne de commande PDF Rasterizer

Contactez le Service clientèle d'AEM pour accéder au fichier cq-dam-pdfrasterizer*.zip pour le système d'exploitation.
Téléchargez le fichier zip sur le serveur AEM.
Décompressez le fichier zip dans un nouveau dossier sur le serveur.
Téléchargez un fichier PDF sur le serveur dans le même dossier que celui où vous avez extrait le fichier zip.

Exécutez cette commande dans ce dossier pour vous assurer que le traceur par ligne fonctionne (remplacez pdffilename.pdf par le nom de fichier du document pdf).

/opt/aem/author62/rasterizer/PDFRasterizer -d -p 1 -s 1280 -t PNG -i pdffilename.pdf

Le résultat correspond à ce qui suit :

Total time in image conversion (in ms): 163
Total time (in ms): 896. Time to initialize: 12. Time for conversion: 884

En plus des étapes de cette page, vous devez également modifier l'étape de workflow de « ressource de mise à jour DAM », « Rasterize PDF/Rendu de l'aperçu des images d'IA ». Supprimez « application/pdf » de la liste des « Types MIME ».
En supposant que le traceur par ligne fonctionne bien sur la ligne de commande, suivez donc toutes les étapes dans cet article pour le configurer afin qu'il fonctionne dans AEM.
Cliquez sur « Enregistrer » pour enregistrer le modèle de workflow.
Désormais, le téléchargement des fichiers PDF et les rendus doivent être générés très rapidement et sans utilisation élevée de la mémoire

Adobe

Recevez de l’aide plus rapidement et plus facilement

Nouvel utilisateur ?