J'ai développé un site en jsp+servlet+beans sous TOMCAT 4.1.28.
Au moins une fois par jour, le site tombe avec comme erreur : out of memory.
Bien que je comprenne le sens de l'erreur, je voudrais avoir l'avis de
développeurs plus expérimentés.
Je précise que nous avons augmenté la mémoire réservée à la JVM au lancement
de tomcat à 350 Mo.
Est-ce parce qu'il y a une trop de connexions simultannement ? est ce
typique de l'utilisation de beans en session ? est ce plutot un mauvais
nettoyage des objets inutilisés ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas Delsaux
Le 12.12 2003, philippe.rebouillat s'est levé et s'est dit : "tiens, si j'écrivais aux mecs de fr.comp.lang.java ?"
Je précise que nous avons augmenté la mémoire réservée à la JVM au lancement de tomcat à 350 Mo.
Tant que ça ? Ca me paraît vraiment énorme, comme valeur.
Est-ce parce qu'il y a une trop de connexions simultannement ?
Utilises-tu des pools de connexion ?
est ce typique de l'utilisation de beans en session ?
Pas vraiment, non : noramlement, tes sessions Tomcat ont des durées d'expiration. Peut-être devrais-tu vérifier que tes beans ne référencent pas de manière permanent des connexions, ou d'autres objets qui devraient être gérés par Tomcat.
est ce plutot un mauvais nettoyage des objets inutilisés ?
Je pense que c'est probablement ça ;-) Le seul problème est de tracer la source de cette fuite de mémoire ! Deux solutions : utiliser, autant que possible, des pools de manière intelligente, et compter le nombre d'instance de chaque classe (je sais, c'est très sale) par le biais d'une variable static privateinstanceCount que tu incrémentes à chaque construction, et que tu décrémentes ... quand tu peux !
Merci de votre aide
-- Nicolas Delsaux "On ne cherche pas à se rendre compte que, pour un enfant de six ans, le passé remonte aussi loin que pour l'homme fait, et que cette route qui s'étend en arrière est toute remplie de détails et d'épisodes" Théodore Sturgeon - Les plus qu'humains
Le 12.12 2003, philippe.rebouillat s'est levé et s'est dit : "tiens, si
j'écrivais aux mecs de fr.comp.lang.java ?"
Je précise que nous avons augmenté la mémoire réservée à la JVM au
lancement de tomcat à 350 Mo.
Tant que ça ? Ca me paraît vraiment énorme, comme valeur.
Est-ce parce qu'il y a une trop de connexions simultannement ?
Utilises-tu des pools de connexion ?
est ce
typique de l'utilisation de beans en session ?
Pas vraiment, non : noramlement, tes sessions Tomcat ont des durées
d'expiration. Peut-être devrais-tu vérifier que tes beans ne référencent
pas de manière permanent des connexions, ou d'autres objets qui devraient
être gérés par Tomcat.
est ce plutot un
mauvais nettoyage des objets inutilisés ?
Je pense que c'est probablement ça ;-)
Le seul problème est de tracer la source de cette fuite de mémoire !
Deux solutions : utiliser, autant que possible, des pools de manière
intelligente, et compter le nombre d'instance de chaque classe (je sais,
c'est très sale) par le biais d'une variable static privateinstanceCount
que tu incrémentes à chaque construction, et que tu décrémentes ... quand
tu peux !
Merci de votre aide
--
Nicolas Delsaux
"On ne cherche pas à se rendre compte que, pour un enfant de six ans, le
passé remonte aussi loin que pour l'homme fait, et que cette route qui
s'étend en arrière est toute remplie de détails et d'épisodes"
Théodore Sturgeon - Les plus qu'humains
Le 12.12 2003, philippe.rebouillat s'est levé et s'est dit : "tiens, si j'écrivais aux mecs de fr.comp.lang.java ?"
Je précise que nous avons augmenté la mémoire réservée à la JVM au lancement de tomcat à 350 Mo.
Tant que ça ? Ca me paraît vraiment énorme, comme valeur.
Est-ce parce qu'il y a une trop de connexions simultannement ?
Utilises-tu des pools de connexion ?
est ce typique de l'utilisation de beans en session ?
Pas vraiment, non : noramlement, tes sessions Tomcat ont des durées d'expiration. Peut-être devrais-tu vérifier que tes beans ne référencent pas de manière permanent des connexions, ou d'autres objets qui devraient être gérés par Tomcat.
est ce plutot un mauvais nettoyage des objets inutilisés ?
Je pense que c'est probablement ça ;-) Le seul problème est de tracer la source de cette fuite de mémoire ! Deux solutions : utiliser, autant que possible, des pools de manière intelligente, et compter le nombre d'instance de chaque classe (je sais, c'est très sale) par le biais d'une variable static privateinstanceCount que tu incrémentes à chaque construction, et que tu décrémentes ... quand tu peux !
Merci de votre aide
-- Nicolas Delsaux "On ne cherche pas à se rendre compte que, pour un enfant de six ans, le passé remonte aussi loin que pour l'homme fait, et que cette route qui s'étend en arrière est toute remplie de détails et d'épisodes" Théodore Sturgeon - Les plus qu'humains
Laurent Bossavit
Le seul problème est de tracer la source de cette fuite de mémoire ! Deux solutions : utiliser, autant que possible, des pools de manière intelligente, et compter le nombre d'instance de chaque classe (je sais, c'est très sale) par le biais d'une variable static privateinstanceCount
Troisième solution, peut-être plus efficace: utiliser un outil spécialisé, comme OptimizeIt Profiler.
http://www.borland.com/optimizeit/
Laurent http://bossavit.com/
Le seul problème est de tracer la source de cette fuite de mémoire !
Deux solutions : utiliser, autant que possible, des pools de manière
intelligente, et compter le nombre d'instance de chaque classe (je sais,
c'est très sale) par le biais d'une variable static privateinstanceCount
Troisième solution, peut-être plus efficace: utiliser un outil
spécialisé, comme OptimizeIt Profiler.
Le seul problème est de tracer la source de cette fuite de mémoire ! Deux solutions : utiliser, autant que possible, des pools de manière intelligente, et compter le nombre d'instance de chaque classe (je sais, c'est très sale) par le biais d'une variable static privateinstanceCount
Troisième solution, peut-être plus efficace: utiliser un outil spécialisé, comme OptimizeIt Profiler.
http://www.borland.com/optimizeit/
Laurent http://bossavit.com/
Karmelitre
philippe.rebouillat wrote:
Je précise que nous avons augmenté la mémoire réservée à la JVM au lancement de tomcat à 350 Mo.
Le pb est probablement que le garbage collector n'arrive pas à desallouer les objets que tu intancies car tu gardes des references dessus, ces references sont faites depuis un pointeur qui a une durée de vie longue : - Session HTTP avec une durée de vie tres longue voir infinie - ServletContext - Attribut statique - .... Ton site gere combien d'utilisateurs simultanés ?
a+ -- Thomas Recloux a.k.a Karmelitre trecloux (à) w3sys (.) net http://www.w3sys.net/trecloux
philippe.rebouillat wrote:
Je précise que nous avons augmenté la mémoire réservée à la JVM au
lancement de tomcat à 350 Mo.
Le pb est probablement que le garbage collector n'arrive pas à desallouer
les objets que tu intancies car tu gardes des references dessus, ces
references sont faites depuis un pointeur qui a une durée de vie longue :
- Session HTTP avec une durée de vie tres longue voir infinie
- ServletContext
- Attribut statique
- ....
Ton site gere combien d'utilisateurs simultanés ?
a+
--
Thomas Recloux a.k.a Karmelitre
trecloux (à) w3sys (.) net
http://www.w3sys.net/trecloux
Je précise que nous avons augmenté la mémoire réservée à la JVM au lancement de tomcat à 350 Mo.
Le pb est probablement que le garbage collector n'arrive pas à desallouer les objets que tu intancies car tu gardes des references dessus, ces references sont faites depuis un pointeur qui a une durée de vie longue : - Session HTTP avec une durée de vie tres longue voir infinie - ServletContext - Attribut statique - .... Ton site gere combien d'utilisateurs simultanés ?
a+ -- Thomas Recloux a.k.a Karmelitre trecloux (à) w3sys (.) net http://www.w3sys.net/trecloux
mehdi kasmi
Essaie aussi de règler tes parametres JVM xms et xmx ...
mais dans ce que tu nous dis ... les objets en session dne sont jamais libérés ... verifie aussi ton temps max pour une session ... generalement fixée à 1800 ms abaisse là ... ensuite essai aussi de voir si le logout fait vbien un release de la session ... @ +
"Karmelitre" wrote in message news:3fdaf17f$0$29087$
philippe.rebouillat wrote:
Je précise que nous avons augmenté la mémoire réservée à la JVM au lancement de tomcat à 350 Mo.
Le pb est probablement que le garbage collector n'arrive pas à desallouer les objets que tu intancies car tu gardes des references dessus, ces references sont faites depuis un pointeur qui a une durée de vie longue : - Session HTTP avec une durée de vie tres longue voir infinie - ServletContext - Attribut statique - .... Ton site gere combien d'utilisateurs simultanés ?
a+ -- Thomas Recloux a.k.a Karmelitre trecloux (à) w3sys (.) net http://www.w3sys.net/trecloux
Essaie aussi de règler tes parametres JVM xms et xmx ...
mais dans ce que tu nous dis ...
les objets en session dne sont jamais libérés ...
verifie aussi ton temps max pour une session ... generalement fixée à 1800
ms
abaisse là ...
ensuite essai aussi de voir si le logout fait vbien un release de la session
...
@ +
"Karmelitre" <PAS_trecloux_DE@PUBLI_w3sys.net_CITE> wrote in message
news:3fdaf17f$0$29087$636a55ce@news.free.fr...
philippe.rebouillat wrote:
Je précise que nous avons augmenté la mémoire réservée à la JVM au
lancement de tomcat à 350 Mo.
Le pb est probablement que le garbage collector n'arrive pas à desallouer
les objets que tu intancies car tu gardes des references dessus, ces
references sont faites depuis un pointeur qui a une durée de vie longue :
- Session HTTP avec une durée de vie tres longue voir infinie
- ServletContext
- Attribut statique
- ....
Ton site gere combien d'utilisateurs simultanés ?
a+
--
Thomas Recloux a.k.a Karmelitre
trecloux (à) w3sys (.) net
http://www.w3sys.net/trecloux
Essaie aussi de règler tes parametres JVM xms et xmx ...
mais dans ce que tu nous dis ... les objets en session dne sont jamais libérés ... verifie aussi ton temps max pour une session ... generalement fixée à 1800 ms abaisse là ... ensuite essai aussi de voir si le logout fait vbien un release de la session ... @ +
"Karmelitre" wrote in message news:3fdaf17f$0$29087$
philippe.rebouillat wrote:
Je précise que nous avons augmenté la mémoire réservée à la JVM au lancement de tomcat à 350 Mo.
Le pb est probablement que le garbage collector n'arrive pas à desallouer les objets que tu intancies car tu gardes des references dessus, ces references sont faites depuis un pointeur qui a une durée de vie longue : - Session HTTP avec une durée de vie tres longue voir infinie - ServletContext - Attribut statique - .... Ton site gere combien d'utilisateurs simultanés ?
a+ -- Thomas Recloux a.k.a Karmelitre trecloux (à) w3sys (.) net http://www.w3sys.net/trecloux
philippe.rebouillat
Bonjour,
Merci de ton aide. Que veux tu dire par "le logout fait vbien un release de la session" ? est ce dans le code ou bien dans la configuration serveur.xml ?
"mehdi kasmi" a écrit dans le message de news: 3fdb574a$0$6972$
Essaie aussi de règler tes parametres JVM xms et xmx ...
mais dans ce que tu nous dis ... les objets en session dne sont jamais libérés ... verifie aussi ton temps max pour une session ... generalement fixée à 1800 ms abaisse là ... ensuite essai aussi de voir si le logout fait vbien un release de la session
... @ +
"Karmelitre" wrote in message news:3fdaf17f$0$29087$
philippe.rebouillat wrote:
Je précise que nous avons augmenté la mémoire réservée à la JVM au lancement de tomcat à 350 Mo.
Le pb est probablement que le garbage collector n'arrive pas à desallouer
les objets que tu intancies car tu gardes des references dessus, ces references sont faites depuis un pointeur qui a une durée de vie longue :
- Session HTTP avec une durée de vie tres longue voir infinie - ServletContext - Attribut statique - .... Ton site gere combien d'utilisateurs simultanés ?
a+ -- Thomas Recloux a.k.a Karmelitre trecloux (à) w3sys (.) net http://www.w3sys.net/trecloux
Bonjour,
Merci de ton aide. Que veux tu dire par "le logout fait vbien un release de
la session" ? est ce dans le code ou bien dans
la configuration serveur.xml ?
"mehdi kasmi" <mehdikasmi@club-internet.fr> a écrit dans le message de news:
3fdb574a$0$6972$7a628cd7@news.club-internet.fr...
Essaie aussi de règler tes parametres JVM xms et xmx ...
mais dans ce que tu nous dis ...
les objets en session dne sont jamais libérés ...
verifie aussi ton temps max pour une session ... generalement fixée à 1800
ms
abaisse là ...
ensuite essai aussi de voir si le logout fait vbien un release de la
session
...
@ +
"Karmelitre" <PAS_trecloux_DE@PUBLI_w3sys.net_CITE> wrote in message
news:3fdaf17f$0$29087$636a55ce@news.free.fr...
philippe.rebouillat wrote:
Je précise que nous avons augmenté la mémoire réservée à la JVM au
lancement de tomcat à 350 Mo.
Le pb est probablement que le garbage collector n'arrive pas à
desallouer
les objets que tu intancies car tu gardes des references dessus, ces
references sont faites depuis un pointeur qui a une durée de vie longue
:
- Session HTTP avec une durée de vie tres longue voir infinie
- ServletContext
- Attribut statique
- ....
Ton site gere combien d'utilisateurs simultanés ?
a+
--
Thomas Recloux a.k.a Karmelitre
trecloux (à) w3sys (.) net
http://www.w3sys.net/trecloux
Merci de ton aide. Que veux tu dire par "le logout fait vbien un release de la session" ? est ce dans le code ou bien dans la configuration serveur.xml ?
"mehdi kasmi" a écrit dans le message de news: 3fdb574a$0$6972$
Essaie aussi de règler tes parametres JVM xms et xmx ...
mais dans ce que tu nous dis ... les objets en session dne sont jamais libérés ... verifie aussi ton temps max pour une session ... generalement fixée à 1800 ms abaisse là ... ensuite essai aussi de voir si le logout fait vbien un release de la session
... @ +
"Karmelitre" wrote in message news:3fdaf17f$0$29087$
philippe.rebouillat wrote:
Je précise que nous avons augmenté la mémoire réservée à la JVM au lancement de tomcat à 350 Mo.
Le pb est probablement que le garbage collector n'arrive pas à desallouer
les objets que tu intancies car tu gardes des references dessus, ces references sont faites depuis un pointeur qui a une durée de vie longue :
- Session HTTP avec une durée de vie tres longue voir infinie - ServletContext - Attribut statique - .... Ton site gere combien d'utilisateurs simultanés ?
a+ -- Thomas Recloux a.k.a Karmelitre trecloux (à) w3sys (.) net http://www.w3sys.net/trecloux
philippe.rebouillat
Merci de ces pistes. Pour répondre à ta question sur les pools : oui, j'utilise un pool de connexion paramètré à 30 Idle conn, et 100 Actives conn. Autrement, quand j'utilise un bean de scope page, il est bien nettoyé à la fin de la page ? Concernant les objets mal nettoyés :
Dernière interrogation. Dans une servlet, je créé un bean de session. Donc je récupère l'object httpsession, ensuite je créé mon objet, et je l'ajoute en session : HttpSession session = request.getSession(); Erreurs err = new Erreurs(); session.setAttribute("erreurs", err); est ce suffisant ? avant de quitter la servlet, dois je faire un truc du genre : err = null; Merci d'avance. Ton aide me sera précieuse car le site plante souvant et c'est pénible (et je me fais engueuler) "Nicolas Delsaux" a écrit dans le message de news:
Le 12.12 2003, philippe.rebouillat s'est levé et s'est dit : "tiens, si j'écrivais aux mecs de fr.comp.lang.java ?"
Je précise que nous avons augmenté la mémoire réservée à la JVM au lancement de tomcat à 350 Mo.
Tant que ça ? Ca me paraît vraiment énorme, comme valeur.
Est-ce parce qu'il y a une trop de connexions simultannement ?
Utilises-tu des pools de connexion ?
est ce typique de l'utilisation de beans en session ?
Pas vraiment, non : noramlement, tes sessions Tomcat ont des durées d'expiration. Peut-être devrais-tu vérifier que tes beans ne référencent pas de manière permanent des connexions, ou d'autres objets qui devraient être gérés par Tomcat.
est ce plutot un mauvais nettoyage des objets inutilisés ?
Je pense que c'est probablement ça ;-) Le seul problème est de tracer la source de cette fuite de mémoire ! Deux solutions : utiliser, autant que possible, des pools de manière intelligente, et compter le nombre d'instance de chaque classe (je sais, c'est très sale) par le biais d'une variable static privateinstanceCount que tu incrémentes à chaque construction, et que tu décrémentes ... quand tu peux !
Merci de votre aide
-- Nicolas Delsaux "On ne cherche pas à se rendre compte que, pour un enfant de six ans, le passé remonte aussi loin que pour l'homme fait, et que cette route qui s'étend en arrière est toute remplie de détails et d'épisodes" Théodore Sturgeon - Les plus qu'humains
Merci de ces pistes.
Pour répondre à ta question sur les pools : oui, j'utilise un pool de
connexion paramètré à 30 Idle conn, et 100 Actives conn.
Autrement, quand j'utilise un bean de scope page, il est bien nettoyé à la
fin de la page ?
Concernant les objets mal nettoyés :
Dernière interrogation. Dans une servlet, je créé un bean de session. Donc
je récupère l'object httpsession, ensuite je créé mon objet, et je l'ajoute
en session :
HttpSession session = request.getSession();
Erreurs err = new Erreurs();
session.setAttribute("erreurs", err);
est ce suffisant ? avant de quitter la servlet, dois je faire un truc du
genre :
err = null;
Merci d'avance. Ton aide me sera précieuse car le site plante souvant et
c'est pénible (et je me fais engueuler)
"Nicolas Delsaux" <nicolas.delsaux@alussinan.org> a écrit dans le message de
news: XnF944F6A171E028nicolasdelsauxalussi@213.228.0.75...
Le 12.12 2003, philippe.rebouillat s'est levé et s'est dit : "tiens, si
j'écrivais aux mecs de fr.comp.lang.java ?"
Je précise que nous avons augmenté la mémoire réservée à la JVM au
lancement de tomcat à 350 Mo.
Tant que ça ? Ca me paraît vraiment énorme, comme valeur.
Est-ce parce qu'il y a une trop de connexions simultannement ?
Utilises-tu des pools de connexion ?
est ce
typique de l'utilisation de beans en session ?
Pas vraiment, non : noramlement, tes sessions Tomcat ont des durées
d'expiration. Peut-être devrais-tu vérifier que tes beans ne référencent
pas de manière permanent des connexions, ou d'autres objets qui devraient
être gérés par Tomcat.
est ce plutot un
mauvais nettoyage des objets inutilisés ?
Je pense que c'est probablement ça ;-)
Le seul problème est de tracer la source de cette fuite de mémoire !
Deux solutions : utiliser, autant que possible, des pools de manière
intelligente, et compter le nombre d'instance de chaque classe (je sais,
c'est très sale) par le biais d'une variable static privateinstanceCount
que tu incrémentes à chaque construction, et que tu décrémentes ... quand
tu peux !
Merci de votre aide
--
Nicolas Delsaux
"On ne cherche pas à se rendre compte que, pour un enfant de six ans, le
passé remonte aussi loin que pour l'homme fait, et que cette route qui
s'étend en arrière est toute remplie de détails et d'épisodes"
Théodore Sturgeon - Les plus qu'humains
Merci de ces pistes. Pour répondre à ta question sur les pools : oui, j'utilise un pool de connexion paramètré à 30 Idle conn, et 100 Actives conn. Autrement, quand j'utilise un bean de scope page, il est bien nettoyé à la fin de la page ? Concernant les objets mal nettoyés :
Dernière interrogation. Dans une servlet, je créé un bean de session. Donc je récupère l'object httpsession, ensuite je créé mon objet, et je l'ajoute en session : HttpSession session = request.getSession(); Erreurs err = new Erreurs(); session.setAttribute("erreurs", err); est ce suffisant ? avant de quitter la servlet, dois je faire un truc du genre : err = null; Merci d'avance. Ton aide me sera précieuse car le site plante souvant et c'est pénible (et je me fais engueuler) "Nicolas Delsaux" a écrit dans le message de news:
Le 12.12 2003, philippe.rebouillat s'est levé et s'est dit : "tiens, si j'écrivais aux mecs de fr.comp.lang.java ?"
Je précise que nous avons augmenté la mémoire réservée à la JVM au lancement de tomcat à 350 Mo.
Tant que ça ? Ca me paraît vraiment énorme, comme valeur.
Est-ce parce qu'il y a une trop de connexions simultannement ?
Utilises-tu des pools de connexion ?
est ce typique de l'utilisation de beans en session ?
Pas vraiment, non : noramlement, tes sessions Tomcat ont des durées d'expiration. Peut-être devrais-tu vérifier que tes beans ne référencent pas de manière permanent des connexions, ou d'autres objets qui devraient être gérés par Tomcat.
est ce plutot un mauvais nettoyage des objets inutilisés ?
Je pense que c'est probablement ça ;-) Le seul problème est de tracer la source de cette fuite de mémoire ! Deux solutions : utiliser, autant que possible, des pools de manière intelligente, et compter le nombre d'instance de chaque classe (je sais, c'est très sale) par le biais d'une variable static privateinstanceCount que tu incrémentes à chaque construction, et que tu décrémentes ... quand tu peux !
Merci de votre aide
-- Nicolas Delsaux "On ne cherche pas à se rendre compte que, pour un enfant de six ans, le passé remonte aussi loin que pour l'homme fait, et que cette route qui s'étend en arrière est toute remplie de détails et d'épisodes" Théodore Sturgeon - Les plus qu'humains
Nicolas Delsaux
Le 15.12 2003, philippe.rebouillat s'est levé et s'est dit : "tiens, si j'écrivais aux mecs de fr.comp.lang.java ?"
Merci de ces pistes. Pour répondre à ta question sur les pools : oui, j'utilise un pool de connexion paramètré à 30 Idle conn, et 100 Actives conn. Autrement, quand j'utilise un bean de scope page, il est bien nettoyé à la fin de la page ?
Il me semble, oui.
Concernant les objets mal nettoyés :
Dernière interrogation. Dans une servlet, je créé un bean de session. Donc je récupère l'object httpsession, ensuite je créé mon objet, et je l'ajoute en session : HttpSession session = request.getSession(); Erreurs err = new Erreurs(); session.setAttribute("erreurs", err); est ce suffisant ? avant de quitter la servlet, dois je faire un truc du genre : err = null;
Ca dépend : si ton objet err n'est pas référencé ailleurs, il sera nettoyé. Si il est référencé en un quelconque autre emplacement du code, ce sera moins déterministe. Je te conseille de te documenter un peu sur la gestion du garbage collector.
Merci d'avance. Ton aide me sera précieuse car le site plante souvant et c'est pénible (et je me fais engueuler)
-- Nicolas Delsaux ZT> Tout nous vient de Crôm, le crédit comme le débit. Enfin, c'est ce ZT> que je me tue à expliquer à mon banquier, qui est un homme de peu ZT> de foi à la tête fort dure. ZT in frjn - Si tu crois pas à Crôm, prends un gnon
Le 15.12 2003, philippe.rebouillat s'est levé et s'est dit : "tiens, si
j'écrivais aux mecs de fr.comp.lang.java ?"
Merci de ces pistes.
Pour répondre à ta question sur les pools : oui, j'utilise un pool de
connexion paramètré à 30 Idle conn, et 100 Actives conn.
Autrement, quand j'utilise un bean de scope page, il est bien nettoyé
à la fin de la page ?
Il me semble, oui.
Concernant les objets mal nettoyés :
Dernière interrogation. Dans une servlet, je créé un bean de session.
Donc je récupère l'object httpsession, ensuite je créé mon objet, et
je l'ajoute en session :
HttpSession session = request.getSession();
Erreurs err = new Erreurs();
session.setAttribute("erreurs", err);
est ce suffisant ? avant de quitter la servlet, dois je faire un truc
du genre :
err = null;
Ca dépend : si ton objet err n'est pas référencé ailleurs, il sera nettoyé.
Si il est référencé en un quelconque autre emplacement du code, ce sera
moins déterministe. Je te conseille de te documenter un peu sur la gestion
du garbage collector.
Merci d'avance. Ton aide me sera précieuse car le site plante souvant
et c'est pénible (et je me fais engueuler)
--
Nicolas Delsaux
ZT> Tout nous vient de Crôm, le crédit comme le débit. Enfin, c'est ce
ZT> que je me tue à expliquer à mon banquier, qui est un homme de peu
ZT> de foi à la tête fort dure.
ZT in frjn - Si tu crois pas à Crôm, prends un gnon
Le 15.12 2003, philippe.rebouillat s'est levé et s'est dit : "tiens, si j'écrivais aux mecs de fr.comp.lang.java ?"
Merci de ces pistes. Pour répondre à ta question sur les pools : oui, j'utilise un pool de connexion paramètré à 30 Idle conn, et 100 Actives conn. Autrement, quand j'utilise un bean de scope page, il est bien nettoyé à la fin de la page ?
Il me semble, oui.
Concernant les objets mal nettoyés :
Dernière interrogation. Dans une servlet, je créé un bean de session. Donc je récupère l'object httpsession, ensuite je créé mon objet, et je l'ajoute en session : HttpSession session = request.getSession(); Erreurs err = new Erreurs(); session.setAttribute("erreurs", err); est ce suffisant ? avant de quitter la servlet, dois je faire un truc du genre : err = null;
Ca dépend : si ton objet err n'est pas référencé ailleurs, il sera nettoyé. Si il est référencé en un quelconque autre emplacement du code, ce sera moins déterministe. Je te conseille de te documenter un peu sur la gestion du garbage collector.
Merci d'avance. Ton aide me sera précieuse car le site plante souvant et c'est pénible (et je me fais engueuler)
-- Nicolas Delsaux ZT> Tout nous vient de Crôm, le crédit comme le débit. Enfin, c'est ce ZT> que je me tue à expliquer à mon banquier, qui est un homme de peu ZT> de foi à la tête fort dure. ZT in frjn - Si tu crois pas à Crôm, prends un gnon
mehdi kasmi
session.invalidate()
"philippe.rebouillat" wrote in message news:3fddbbfc$0$22331$
Bonjour,
Merci de ton aide. Que veux tu dire par "le logout fait vbien un release de
la session" ? est ce dans le code ou bien dans la configuration serveur.xml ?
"mehdi kasmi" a écrit dans le message de news:
3fdb574a$0$6972$
Essaie aussi de règler tes parametres JVM xms et xmx ...
mais dans ce que tu nous dis ... les objets en session dne sont jamais libérés ... verifie aussi ton temps max pour une session ... generalement fixée à 1800
ms abaisse là ... ensuite essai aussi de voir si le logout fait vbien un release de la session
... @ +
"Karmelitre" wrote in message news:3fdaf17f$0$29087$
philippe.rebouillat wrote:
Je précise que nous avons augmenté la mémoire réservée à la JVM au lancement de tomcat à 350 Mo.
Le pb est probablement que le garbage collector n'arrive pas à desallouer
les objets que tu intancies car tu gardes des references dessus, ces references sont faites depuis un pointeur qui a une durée de vie longue
:
- Session HTTP avec une durée de vie tres longue voir infinie - ServletContext - Attribut statique - .... Ton site gere combien d'utilisateurs simultanés ?
a+ -- Thomas Recloux a.k.a Karmelitre trecloux (à) w3sys (.) net http://www.w3sys.net/trecloux
session.invalidate()
"philippe.rebouillat" <philippe.rebouillat@1000bases.com> wrote in message
news:3fddbbfc$0$22331$626a54ce@news.free.fr...
Bonjour,
Merci de ton aide. Que veux tu dire par "le logout fait vbien un release
de
la session" ? est ce dans le code ou bien dans
la configuration serveur.xml ?
"mehdi kasmi" <mehdikasmi@club-internet.fr> a écrit dans le message de
news:
3fdb574a$0$6972$7a628cd7@news.club-internet.fr...
Essaie aussi de règler tes parametres JVM xms et xmx ...
mais dans ce que tu nous dis ...
les objets en session dne sont jamais libérés ...
verifie aussi ton temps max pour une session ... generalement fixée à
1800
ms
abaisse là ...
ensuite essai aussi de voir si le logout fait vbien un release de la
session
...
@ +
"Karmelitre" <PAS_trecloux_DE@PUBLI_w3sys.net_CITE> wrote in message
news:3fdaf17f$0$29087$636a55ce@news.free.fr...
philippe.rebouillat wrote:
Je précise que nous avons augmenté la mémoire réservée à la JVM au
lancement de tomcat à 350 Mo.
Le pb est probablement que le garbage collector n'arrive pas à
desallouer
les objets que tu intancies car tu gardes des references dessus, ces
references sont faites depuis un pointeur qui a une durée de vie
longue
:
- Session HTTP avec une durée de vie tres longue voir infinie
- ServletContext
- Attribut statique
- ....
Ton site gere combien d'utilisateurs simultanés ?
a+
--
Thomas Recloux a.k.a Karmelitre
trecloux (à) w3sys (.) net
http://www.w3sys.net/trecloux
"philippe.rebouillat" wrote in message news:3fddbbfc$0$22331$
Bonjour,
Merci de ton aide. Que veux tu dire par "le logout fait vbien un release de
la session" ? est ce dans le code ou bien dans la configuration serveur.xml ?
"mehdi kasmi" a écrit dans le message de news:
3fdb574a$0$6972$
Essaie aussi de règler tes parametres JVM xms et xmx ...
mais dans ce que tu nous dis ... les objets en session dne sont jamais libérés ... verifie aussi ton temps max pour une session ... generalement fixée à 1800
ms abaisse là ... ensuite essai aussi de voir si le logout fait vbien un release de la session
... @ +
"Karmelitre" wrote in message news:3fdaf17f$0$29087$
philippe.rebouillat wrote:
Je précise que nous avons augmenté la mémoire réservée à la JVM au lancement de tomcat à 350 Mo.
Le pb est probablement que le garbage collector n'arrive pas à desallouer
les objets que tu intancies car tu gardes des references dessus, ces references sont faites depuis un pointeur qui a une durée de vie longue
:
- Session HTTP avec une durée de vie tres longue voir infinie - ServletContext - Attribut statique - .... Ton site gere combien d'utilisateurs simultanés ?
a+ -- Thomas Recloux a.k.a Karmelitre trecloux (à) w3sys (.) net http://www.w3sys.net/trecloux
Franck
philippe.rebouillat wrote:
J'ai développé un site en jsp+servlet+beans sous TOMCAT 4.1.28. Au moins une fois par jour, le site tombe avec comme erreur : out of memory.
Bien que je comprenne le sens de l'erreur, je voudrais avoir l'avis de développeurs plus expérimentés.
Je précise que nous avons augmenté la mémoire réservée à la JVM au lancement de tomcat à 350 Mo.
Est-ce parce qu'il y a une trop de connexions simultannement ? est ce typique de l'utilisation de beans en session ? est ce plutot un mauvais nettoyage des objets inutilisés ?
Merci de votre aide
De mon expérience sur les serveurs d'applications Java (mais pas Tomcat), Ce genre de problèmes est quasi toujours du à des ressources non liberées comme : - des connections sql pas close() - des resultsets sql pas close() - ou des inputStream / outputStream pas close()
Vérifie tous ces éléments et vérifie qu'en cas d'anomalie toutes ces ressources sont libérées dans tous les cas (try{} catch{} finally{ truc.close() } )
@+ -- Franck Lefebure mailto:
philippe.rebouillat wrote:
J'ai développé un site en jsp+servlet+beans sous TOMCAT 4.1.28.
Au moins une fois par jour, le site tombe avec comme erreur : out of
memory.
Bien que je comprenne le sens de l'erreur, je voudrais avoir l'avis de
développeurs plus expérimentés.
Je précise que nous avons augmenté la mémoire réservée à la JVM au
lancement de tomcat à 350 Mo.
Est-ce parce qu'il y a une trop de connexions simultannement ? est ce
typique de l'utilisation de beans en session ? est ce plutot un
mauvais nettoyage des objets inutilisés ?
Merci de votre aide
De mon expérience sur les serveurs d'applications Java (mais pas Tomcat),
Ce genre de problèmes est quasi toujours du à des ressources non liberées
comme :
- des connections sql pas close()
- des resultsets sql pas close()
- ou des inputStream / outputStream pas close()
Vérifie tous ces éléments et vérifie qu'en cas d'anomalie toutes ces
ressources
sont libérées dans tous les cas (try{} catch{} finally{ truc.close() } )
J'ai développé un site en jsp+servlet+beans sous TOMCAT 4.1.28. Au moins une fois par jour, le site tombe avec comme erreur : out of memory.
Bien que je comprenne le sens de l'erreur, je voudrais avoir l'avis de développeurs plus expérimentés.
Je précise que nous avons augmenté la mémoire réservée à la JVM au lancement de tomcat à 350 Mo.
Est-ce parce qu'il y a une trop de connexions simultannement ? est ce typique de l'utilisation de beans en session ? est ce plutot un mauvais nettoyage des objets inutilisés ?
Merci de votre aide
De mon expérience sur les serveurs d'applications Java (mais pas Tomcat), Ce genre de problèmes est quasi toujours du à des ressources non liberées comme : - des connections sql pas close() - des resultsets sql pas close() - ou des inputStream / outputStream pas close()
Vérifie tous ces éléments et vérifie qu'en cas d'anomalie toutes ces ressources sont libérées dans tous les cas (try{} catch{} finally{ truc.close() } )
