OutOfMemoryError: PermGen Space — Jasper Rapport avec le Printemps en cours d'exécution sur Tomcat

Notre application web rencontre une situation compliquée

C'est un Printemps application développée par STS/Tomcat 7. Après l'application a été intégrée avec Jasper report 4.6.0, il est toujours jeter " OutOfMemoryError: PermGen Space. Alors la seule façon de le faire fonctionner est de redémarrer l'application. Mais après un moment il se produire à nouveau.
Voici journal avant de l'exception:

Oct 17, 2012 3:42:27 PM org.apache.jasper.compiler.TldLocationsCache tldScanJar
INFO: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
Oct 17, 2012 3:42:30 PM org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet jsp threw exception

Ici est une section de l'exception, où j'ai trouvé quelque chose à propos de Jasper:

at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:442)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:378)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:353)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:340)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:646)
at org.apache.jasper.servlet.JspServletWrapper.loadTagFile(JspServletWrapper.java:240)
at org.apache.jasper.compiler.TagFileProcessor.loadTagFile(TagFileProcessor.java:578)
at org.apache.jasper.compiler.TagFileProcessor.access$000(TagFileProcessor.java:49)
at org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(TagFileProcessor.java:655)

Voici quelques résultats lorsque la situation se produit:

  1. Le problème peut se produire sur la page sans Jasper composants de Rapport. Il semble que le Jaspe Rapport bean est d'essayer de trouver un tag lib tout le temps quand a request is processed by the back end and responded to the front end. Normalement à partir du fichier journal, je peux voir exception ci-dessus ne seront pas jeter jusqu'à ce que toutes les opérations de back-end(JPA de gestion) sont complètes

  2. Lors de l'exécution à log4J sur le mode debug, je vois des tonnes d'informations montrant quelque chose comme l'analyse/le rendu de tous les composants de Jasper modèle(textfields, stylo, boîte...), il y a une petite coupure à partir du grand journal:

    2012-10-17 15:29:12,025 -- DEBUG -- org.apache.commons.digester.Digester.sax -- startElement(http://jasperreports.sourceforge.net/jasperreports,textElement,textElement)
2012-10-17 15:29:12,025 -- DEBUG -- org.apache.commons.digester.Digester --   Pushing body text ''
2012-10-17 15:29:12,025 -- DEBUG -- org.apache.commons.digester.Digester --   New match='jasperReport/summary/band/textField/textElement'
2012-10-17 15:29:12,025 -- DEBUG -- org.apache.commons.digester.Digester --   Fire begin() for FactoryCreateRule[className=net.sf.jasperreports.engine.xml.JRTextElementFactory, attributeName=null, creationFactory=net.sf.jasperreports.engine.xml.JRTextElementFactory@12dc6007]
2012-10-17 15:29:12,025 -- DEBUG -- org.apache.commons.digester.Digester -- [FactoryCreateRule]{jasperReport/summary/band/textField/textElement} New net.sf.jasperreports.engine.design.JRDesignTextField
2012-10-17 15:29:12,025 -- DEBUG -- org.apache.commons.digester.Digester.sax -- ignorableWhitespace()

    Encore, ce journal est généré lorsqu'une requête à la page qui ne contient pas tout Jasper composant.

J'ai fait quelques recherches mais ne trouve toujours pas la solution à ce problème.

  1. La première question est la même il y a une jasperreport bean dans l'application pour laquelle il est toujours en cours d'exécution lorsque ce n'est même pas autocâblés avec le service actuel(le sens de la page en cours n'ont pas de jasper composant). Est-il une solution/réponse à cette situation?

  2. Également à partir du message de l'exception
    Au moins un POT a été analysé pour les Tld encore contenait pas de Tld.
    au org.apache.jasper.compilateur.JDTCompiler.generateClass(JDTCompiler.java:442)

    devraient vient de Tomcat, et Tomcat never contains any JSTL jar, alors je suppose qu'il ne peut pas trouver une correspondance TLD pour analyser jasper rapport donc à faire un scan complet de tous les pots. Si oui, alors comment se fait-il existe une grande quantité de journaux de débogage de org.apache.commons.digester.Digester semble effectivement occupé sur l'analyse du modèle jasper?

En général, font de ce thread est juste essayer de trouver une solution au problème, et aussi de trouver une réponse à pourquoi Jasper est actif sur un lieu n'en a pas besoin, et comment nous pouvons laisser tomcat correctement analysé les modèles?

M'excuse si trop verbeux, et merci pour tout les conseils.

Alors, avez-vous essayé d'augmenter la taille de la PermGen? Ce n'est pas comme il ya beaucoup d'autres façons.
Pavageau oui j'ai essayé, de le mettre à 512M, mais toujours obtenir la même question...est-il dans le catalina.sh et JAVA_OPTS="...-XX:MaxPermSize=512m..." ?
il semble jasper reports ont ce genre de problèmes avec certaines configurations, afin de dépanner la cause de jasper reports pourrait très bien être faisable.
merci de m'éclairer sur la façon de tracer la cause de racine de Jasper Rapport ou je devrais essayer HeapDumpOnOutOfMemoryError ? Merci.
essayez de faire cela, obtenir un tas de vidage de la condition d'erreur et d'analyse qui devrait être un pas en avant

OriginalL'auteur Dreamer | 2012-10-17

  1. 8

    Merci tout le monde pour donner la solution sur ce problème, j'ai identifié le problème plus précisément ma situation et voici la solution:

    Utilisation .jasper au lieu de .jrxml en tant que modèle !

    Comme nous le savons .jasper est un modèle compilé ainsi que .jrxml est ASCII de code source pour le modèle, donc si l'on utilise raw fichier de code source (jrxml) en tant que modèle dans le courant du printemps application puis au moins le printemps de cadre de travail a pour compiler le code source du fichier. C'est une question d'efficacité gauche au framework Spring comme c'est le jaspe de la fève à la poignée de la compilation et il n'est pas garanti la compilation exécutée qu'une seule fois et ne se produit lorsque de départ de l'application.

    Bref, après remplacer tous les modèles avec des .jasper fichier, la taille du journal a été réduite de manière significative et n'ont pas vu le hors de question de la mémoire. Je suppose que le Printemps conteneur peut être consommer beaucoup de ressources pour compiler jrxml à jasper, au moment de l'exécution. Donc il pourrait être quelque chose devrait avons amélioré par Jasper ou de Printemps....

    c'est exactement ce dont j'avais besoin merci..

    OriginalL'auteur Dreamer

  2. 7

    L'exception se produit quand il y a trop .les fichiers de classe dans le permgen space dans la JVM qui ne peut pas être nettoyée en raison de ses références à un objet à l'extérieur de la AppClassLoader. Généralement, il rappelle à la mémoire de fuite de votre application.

    Cette post a une explication lucide de java.lang.OutOfMemoryError: PermGen space erreur et une post a des suggestions sur la façon de le résoudre.
    Un semblable (mais pas exactement le même) question a demandé, vous permettant de savoir si vous l'avez manqué. J'espère que cela aide.

    Que jakub a mentionné le paramétrage de -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled ou réglage d'une valeur plus élevée pour XX:MaxPermSize pourraient travailler pour vous. Mais de ce que j'ai lu, ce n'est pas une solution permanente, il me semble. (Je ne suis pas un maitre dans ce :)).

    Nice postes sur les liens. Si quelqu'un a besoin de quelques précisions sur ce qu'il se passe de mieux lire ces messages. Je vous remercie.

    OriginalL'auteur shazinltc

  3. 2

    Essayer de régler ces paramètres dans votre VM. Celles-ci doivent permettre GC nettoyage de votre permGen.

    -XX:+UseConcMarkSweepGC
-XX:+CMSPermGenSweepingEnabled
-XX:+CMSClassUnloadingEnabled
    Je vous remercie. Êtes-vous sûr que nous le faisons à la JVM pas de Tomcat? Est-il des performances de l'impact de ce changement?
    Le PermGen OOM se produit généralement parce que le GC a couru, mais n'a pas pu libérer de la mémoire, non pas parce que la GC n'est pas de prendre soin de la PermGen.
    effectivement diagnoze quel est le problème, vous devez ajouter également -XX:+HeapDumpOnOutOfMemoryError donc, vous obtiendrez un tas de vidage. Pas sûr si cela fonctionne sur permgen erreur, mais je vous recommande d'essayer. Ce tas de vidage doit être exécutée par l'intermédiaire avec MAT ou similaire.
    Oui, vous devez définir ces dans la configuration de Tomcat, donc quand il commence VM pour vos applications qu'il commence avec ces paramètres. Nous sommes à l'aide de ces avec GlassFish et ne pas l'avis de tout impact sur les performances, juste PermGen erreur de cesse de montrer.

    OriginalL'auteur jakub.petr

  4. 2

    J'ai développé une application web qui utilise JasperReports 4.5.1

    J'utilise Tomcat 6.0.26 comme un conteneur. (Win7, JDK 1.6.0_25)

    Lors de l'arrêt de tomcat,il jeter :

    L'application web créé un ThreadLocal avec clé de type [net.sf.jasperreports.moteur.util.JRFontUtil$1] (valeur [net.sf.jasperreports.moteur.util.JRFontUtil$1@7892f1]) et une valeur de type [java.util.HashSet] ([[]]), mais pas réussi à le retirer lors de l'application web a été arrêté. Ce qui est très susceptible de créer une fuite de mémoire.

    Veuillez visiter le site web:

    http://community.jaspersoft.com/questions/534340/memory-leak-jr-373

    OriginalL'auteur sfxm

  5. 0

    Depuis le PermGen contient essentiellement de la classe de métadonnées, et de la constante et de l'internement des Chaînes, vous pouvez effectuer une recherche dans deux directions:

    • vérifier que la webapp ne contient pas (trop) inutile pots, qui pourraient être chargé en raison de la numérisation

    • voir si vous avez beaucoup de chaines (beaucoup de grandes pages Jsp, par exemple) à l'aide d'un heap dump, ou si votre code utilise la Chaîne.stagiaire()

    En fait, vous n'avez pas à spécifier la version de Java que vous utilisez: avec Java 7, la Chaîne peut ne pas être un problème.

    Ce que vous pourriez faire est d'observer l'application avec JVisualVM, à l'aide de la VisualGC plugin, pour voir l'état des générations, le nombre de classes chargées, et si il y a une montée en soit, au moment de la OOM, ou si c'est une construction lente.

    OriginalL'auteur Frank Pavageau