[Tomcat][Spring] Problème utilisation mémoire

Bonjour

Je réalise une application avec les outils suivants :
- Tomcat
- Spring
- Hibernate

Je developpe sous Eclipse / Win XP + plugin sysdeo

Je constate que mon application a tendance à prendre une place incroyable en mémoire. Comme je suis nouveau dans le développement J2EE, je ne sais pas si ceci est "normal".
Lors du démarage de Tomcat l'espace mémoire utilisé est de 38Mo environ. Au fil de l'exécution de requetes, cette taille explose sans que je ne connaisse ni ne comprenne la cause. Plus la requete a de résultat plus la taille de la mémoire utilisée par tomcat augmente.
Lorsque que mon appli effectue une requete, cela passe par hibernate qui me retourne un graphe d'objet. Je passe ce graphe à ma jsp qui affiche le résultat. A partir de là, le garbage collector est cencé détruire les objets ... mais cela n'a pas l'air d'etre le cas.
Je met bien quelques informations dans la session mais pas plus de quelques centaines d'octets, le problème ne vient donc surrement pas de là.

Problème : lorsque mon appli seras en production, la mémoire rique d'etre tres rapidement saturée du fait du grand nombre de requetes utilisateur.

J'aimerais savoir d'ou peut venir mon pb; savoir si vous pensez qu'une utilisation aussi importante de la mémoire est normale; pourquoi le garbage collector de libere apparement pas la mémoire prise par mes objets, fuite mémoire? ...
Je sais qu'il existe des outils permettant de visualiser l'utilisation de la mémoire, mais en existe t'il pour des applications J2EE / Tomcat? lesquels?

Je suis a l'écoute de toute proposition, mon stage fini d'ici peu, je souhaiterais résoudre ce problème.

Merci d'avance

Tomcat : -Xmx200M
Hibernate : ehcache désactivé

Bonjour,

Citation:

---

Lorsque que mon appli effectue une requete, cela passe par hibernate qui me retourne un graphe d'objet. Je passe ce graphe à ma jsp qui affiche le résultat. A partir de là, le garbage collector est cencé détruire les objets

---

En fait pas forcemment, il ne détruit que les objets sans référence.

1 - Ton bean est probablement stocké en session et sa destruction dépend de son scope.

2 - La session Hibernate joue le rôle de cache de 1er niveau et lorsque tu effectue une requête, les objets sont stockés dans ce cache (a moins de clore la session ou de la purger).

Bref il n'y a pas de recette miracle, la meilleure solution est d'utiliser un profiler.
Moi pour J2EE j'utilise JProfiler et YourKit Java Profiler (commercial mais une version d'évaluation existe)

Merci pour votre réponse

1) De quel bean parlez vous?
(Désolé, j'ai un peu de mal a comprendre, je ne maitrise pas trop trop mon sujet)
Si "bean" = graphe d'objet en provenance d'hibernate.
Je ne pense pas le stocker en session. Il est stocké dans l'objet "HttpServletResponse response". L'objet response étant détruit une fois la requete terminée, il doit en être de même pour mon graphe d'objet. (théorie)

2)Comme j'utilise Spring, j'utilise certaines "abstractions" (SessionFactory et HibernateTemplate). Je ne touche à aucun moment à la session d'hibernate. Je supose que les développeur de Spring ont pensé à clore la session ou à la purger, mais effectivement je n'en suis pas sur. C'est donc à vérifier.

Je télécharge JProfile, je teste, et si je trouve une solution j'en ferais par.

Merci

par bean j'entend l'objet affiché dans ta JSP (c'est vrai que dans Struts ou Spring on parle plus de Form).
Il est stocké dans la session Http pour être exploité dans la JSP.

Même si cela est gérée entierement par Spring (ou struts) tu peux (doit) décider de la portée de ton bean.

Dans Spring c'est la propriété "sessionForm" qui détermine la portée du bean (uniquement pendant la requette ou durant toute la validité de la session).


Concernant Hibernate je pense qu'une session Hibernate est liée à un HibernateTemplate. Cela dépend donc de ta facon d'utiliser les HibernateTemplate (1 HibernateTemplate par transaction, par requete, pour tout le monde, etc ..)

Spring manquerai de souplesse si des opérations comme close() et clear() étaient effectuées automatiquement.

g le meme probleme avec spring + struts + hibernate, au début l'appli fait 80mo, elle augmente jusqu'a la limite Xmx, à chaque requete, meme avec une seule session.

avec struts, chaque requete déclenche le chargement d'une Action par requete par défaut. je pense que ce doit être la meme chose avec springweb.

Tu peux implémenter un filtre qui liste toutes les variables (session & requete) pour vérifier ce qu'il garde en mémoire.

Je vais commnencer a faire aussi la chasse aux fuites mémoire...

Fonctionnement d'hibernateTemplate :

- si une session a été ouverte, hibernateTemplate s'inscrit dans la transaction en court associée et ne ferme pas la transaction
- si aucune session ouverte, hibernateTemplate ouvre une session et une transaction. La transaction est commitée et la session fermée à la fin de l'appel à hibernateTemplate.

Quel framework web utilises tu ? Struts, Spring MVC ? un truc perso ?
Si tu utilises Spring MVC, tu dois passer ton modèle à la vue en utilsant l'objet ModelAndView.
Si tu utilises Struts, mets le dans ton objet HttpServletRequest.
Je sais qu'il y a des problèmes de mémoire avec Tomcat dans le cas de nombreux redéploiements mais le problème vient des librairies utilisées (CGLIB) plutot que des frameworks (Spring, Hibernate). Regarde du côté du forum de Spring pour plus d'infos.

Citation:

---

Envoyé par Pietra

par bean j'entend l'objet affiché dans ta JSP (c'est vrai que dans Struts ou Spring on parle plus de Form).

---

Ce n'est pas pas totalement exact pour Struts, l'ActionForm de Struts est intimement lié à un formulaire.
Et c'est faux pour Spring, on parle d'objet command qui n'hérite d'aucune classe du framework et n'implémente aucune interface particulière. Ca peut parfaitement être un objet métier sans rapport avec Spring.

Citation:

---

Envoyé par mauvais_karma

avec struts, chaque requete déclenche le chargement d'une Action par requete par défaut. je pense que ce doit être la meme chose avec springweb.

---

Pour Spring, l'applicationContext crée une seule référence pour chaque bean. Le comportement par défaut est donc d'utiliser des singletons. Ce comportement peut être modifié par configuration, on dit alors que l'applicationContext utilise des prototypes (voir le pattern du GoF).

J'utilise Spring MVC, je fait donc transiter mes objets dans ModelAndView (j'ai indiqué "HttpServletResponse response" dans un post précédent, mais c'était une erreur).

J'ai relu mon code, mais il est peu probable que j'ai une fuite mémoire. Je ne vois pas où cela pourrait être possible.

Une des possibilité comme l'indique Pietra est qu'Hibernate mette en cache de niveau 1 le résultat de mes requetes.

J'ai essayé "getHibernateTemplate.clear()" (Remove all objects from the Session cache, and cancel all pending saves, updates and deletes.) mais sans résultat apparant (c'est même plustot l'inverse (+70Mo en une requete :( )!).

J'utilise HibernateDaoSupport si ca peut aider

Merci de votre aide en tout cas, je retourne à JProfiler qui est un peu capricieux ... malheureusement

Tu as vérifié que tu étais en Lazy-collection, si tu as beaucoup de relations entre tes entités, dès que tu vas charger un objet, tu vas charger toutes les entités reliées et les entités reliées aux entités reliées ... ?

nico> ca explique pas pkoi la mémoire grossit a chaque requete, vu que les objets chargés dans la session sont détruits au session.close()

Citation:

---

Envoyé par mauvais_karma

nico> ca explique pas pkoi la mémoire grossit a chaque requete, vu que les objets chargés dans la session sont détruits au session.close()

---

Faux. Les objets ne sont plus associés à la session après le session.close(). Par contre, ils peuvent toujours être présent en mémoire.

c vrai!

Salut,

J'ai une erreur de ce type aussi avec Struts/Hibernate/Tomcat 5.5. En fait, après un certain nombre de redéploiements de l'application, j'ai une PermgenSpace...

J'avais cherché un peu sur le net et sur le forum d'Hibernate...Malheureusement, le sujet est ouvert depuis Nov. 2004 et il est toujours d'actualité et ils n'arrivent pas chez Hibernate à trouver la solution...

Le sujet en question : http://forum.hibernate.org/viewtopic.php?t=935948

Si quelqu'un a tout de même trouvé la solution, je suis preneur !