J'aimerais savoir comment se comportent les variables statiques lorsqu'on
recharge un contexte (dans tomcat par ex.).
Imaginons que j'ai une classe A :
Code:
public class A
{
private static Integer[] staticMember;
static
{
staticMember = new Integer[100];
for ( int i = 0; i < staticMember.length; i++ )
{
staticMember[i] = new Integer(i);
}
}
...
Est-ce que le contenu du tableau sera effacé lorsque le contexte sera
rechargé ?
Le problème, c'est que j'ai sans arrêt des OutOfMemoryError dans Tomcat avec
Hibernate et il me semble qu'à chaque fois que je redémarre mon contexte, la
configuration est rechargée en mémoire et au bout de cinq ou six fois je
suis à 120MB et ça plante :-(
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
SL
LR wrote:
Salut,
J'aimerais savoir comment se comportent les variables statiques lorsqu'on recharge un contexte (dans tomcat par ex.).
Imaginons que j'ai une classe A :
Code:
public class A { private static Integer[] staticMember;
static { staticMember = new Integer[100]; for ( int i = 0; i < staticMember.length; i++ ) { staticMember[i] = new Integer(i); } } ...
Est-ce que le contenu du tableau sera effacé lorsque le contexte sera rechargé ?
oui, le tableau et evidemment son contenu sont dereferences.
le terme effacé n'est pas vraiment adapté ;)
Le problème, c'est que j'ai sans arrêt des OutOfMemoryError dans Tomcat avec Hibernate et il me semble qu'à chaque fois que je redémarre mon contexte, la configuration est rechargée en mémoire et au bout de cinq ou six fois je suis à 120MB et ça plante :-(
Merci d'avance Lilian
desole j'ai pas d'infos pour le probleme hibernate.
-- SL
LR wrote:
Salut,
J'aimerais savoir comment se comportent les variables statiques lorsqu'on
recharge un contexte (dans tomcat par ex.).
Imaginons que j'ai une classe A :
Code:
public class A
{
private static Integer[] staticMember;
static
{
staticMember = new Integer[100];
for ( int i = 0; i < staticMember.length; i++ )
{
staticMember[i] = new Integer(i);
}
}
...
Est-ce que le contenu du tableau sera effacé lorsque le contexte sera
rechargé ?
oui,
le tableau et evidemment son contenu sont dereferences.
le terme effacé n'est pas vraiment adapté ;)
Le problème, c'est que j'ai sans arrêt des OutOfMemoryError dans Tomcat avec
Hibernate et il me semble qu'à chaque fois que je redémarre mon contexte, la
configuration est rechargée en mémoire et au bout de cinq ou six fois je
suis à 120MB et ça plante :-(
Merci d'avance
Lilian
desole j'ai pas d'infos pour le probleme hibernate.
J'aimerais savoir comment se comportent les variables statiques lorsqu'on recharge un contexte (dans tomcat par ex.).
Imaginons que j'ai une classe A :
Code:
public class A { private static Integer[] staticMember;
static { staticMember = new Integer[100]; for ( int i = 0; i < staticMember.length; i++ ) { staticMember[i] = new Integer(i); } } ...
Est-ce que le contenu du tableau sera effacé lorsque le contexte sera rechargé ?
oui, le tableau et evidemment son contenu sont dereferences.
le terme effacé n'est pas vraiment adapté ;)
Le problème, c'est que j'ai sans arrêt des OutOfMemoryError dans Tomcat avec Hibernate et il me semble qu'à chaque fois que je redémarre mon contexte, la configuration est rechargée en mémoire et au bout de cinq ou six fois je suis à 120MB et ça plante :-(
Merci d'avance Lilian
desole j'ai pas d'infos pour le probleme hibernate.
-- SL
LR
J'aimerais savoir comment se comportent les variables statiques lorsqu'on recharge un contexte (dans tomcat par ex.).
Imaginons que j'ai une classe A :
Code:
public class A { private static Integer[] staticMember;
static { staticMember = new Integer[100]; for ( int i = 0; i < staticMember.length; i++ ) { staticMember[i] = new Integer(i); } } ...
Est-ce que le contenu du tableau sera effacé lorsque le contexte sera rechargé ?
oui, le tableau et evidemment son contenu sont dereferences.
le terme effacé n'est pas vraiment adapté ;)
Merci pour ta réponse, et tu as raison, je devrais prendre l'habitude d'utiliser les termes adaptés lorsque je poste sur des forums ;-) A+Lilian
J'aimerais savoir comment se comportent les variables statiques lorsqu'on
recharge un contexte (dans tomcat par ex.).
Imaginons que j'ai une classe A :
Code:
public class A
{
private static Integer[] staticMember;
static
{
staticMember = new Integer[100];
for ( int i = 0; i < staticMember.length; i++ )
{
staticMember[i] = new Integer(i);
}
}
...
Est-ce que le contenu du tableau sera effacé lorsque le contexte sera
rechargé ?
oui,
le tableau et evidemment son contenu sont dereferences.
le terme effacé n'est pas vraiment adapté ;)
Merci pour ta réponse, et tu as raison, je devrais prendre l'habitude
d'utiliser les termes adaptés lorsque je poste sur des forums ;-)
A+Lilian
J'aimerais savoir comment se comportent les variables statiques lorsqu'on recharge un contexte (dans tomcat par ex.).
Imaginons que j'ai une classe A :
Code:
public class A { private static Integer[] staticMember;
static { staticMember = new Integer[100]; for ( int i = 0; i < staticMember.length; i++ ) { staticMember[i] = new Integer(i); } } ...
Est-ce que le contenu du tableau sera effacé lorsque le contexte sera rechargé ?
oui, le tableau et evidemment son contenu sont dereferences.
le terme effacé n'est pas vraiment adapté ;)
Merci pour ta réponse, et tu as raison, je devrais prendre l'habitude d'utiliser les termes adaptés lorsque je poste sur des forums ;-) A+Lilian
ludo06
LR wrote:
Salut,
J'aimerais savoir comment se comportent les variables statiques lorsqu'on recharge un contexte (dans tomcat par ex.).
Imaginons que j'ai une classe A :
Code:
public class A { private static Integer[] staticMember;
static { staticMember = new Integer[100]; for ( int i = 0; i < staticMember.length; i++ ) { staticMember[i] = new Integer(i); } } ...
Est-ce que le contenu du tableau sera effacé lorsque le contexte sera rechargé ?
Le problème, c'est que j'ai sans arrêt des OutOfMemoryError dans Tomcat avec Hibernate et il me semble qu'à chaque fois que je redémarre mon contexte, la configuration est rechargée en mémoire et au bout de cinq ou six fois je suis à 120MB et ça plante :-(
Merci d'avance Lilian
Une supposition: est que la classe A ne serait pas
serializee/deserializee quand tu recharge le contexte, et comme tu cree sans doute une nouvelle session pour retester les sessions precendentes occupent encore de la place en memoire. Tu as verifie le nombre de sessions ouvertes ? (detrompez moi)
Sinon un des memory leak de tomcat (enfin de javac) est la recompilation des jsps. C'est pour ca que pour avoir une applis "pro" sans fuite de memoire, et avec de bien meilleures performances (detrompez moi), en general on precompile ses jsps (ca interdit de les modifier a chaud mais bon en production on touche pas trop les applis normalement).
D'un autre cote comme je ne connais hibernate qu'en surface je n'imagine pas trop les problemes de gestion de memoire qu'il peut avoir c'est pour ca que je te parle des autres problemes potentiels dans tomcat, un expert te repondra sans doute popur hibernate,
Et je t'accorde que le profiling/debogage de Tomcat a chaud demande un peu d'experience :-) (enfin surtout pour mettre le bon classpath apres tout ;-)
J'aimerais savoir comment se comportent les variables statiques lorsqu'on
recharge un contexte (dans tomcat par ex.).
Imaginons que j'ai une classe A :
Code:
public class A
{
private static Integer[] staticMember;
static
{
staticMember = new Integer[100];
for ( int i = 0; i < staticMember.length; i++ )
{
staticMember[i] = new Integer(i);
}
}
...
Est-ce que le contenu du tableau sera effacé lorsque le contexte sera
rechargé ?
Le problème, c'est que j'ai sans arrêt des OutOfMemoryError dans Tomcat avec
Hibernate et il me semble qu'à chaque fois que je redémarre mon contexte, la
configuration est rechargée en mémoire et au bout de cinq ou six fois je
suis à 120MB et ça plante :-(
Merci d'avance
Lilian
Une supposition: est que la classe A ne serait pas
serializee/deserializee quand tu recharge le contexte, et comme tu cree
sans doute une nouvelle session pour retester les sessions precendentes
occupent encore de la place en memoire. Tu as verifie le nombre de
sessions ouvertes ? (detrompez moi)
Sinon un des memory leak de tomcat (enfin de javac) est la recompilation
des jsps. C'est pour ca que pour avoir une applis "pro" sans fuite de
memoire, et avec de bien meilleures performances (detrompez moi), en
general on precompile ses jsps (ca interdit de les modifier a chaud mais
bon en production on touche pas trop les applis normalement).
D'un autre cote comme je ne connais hibernate qu'en surface je n'imagine
pas trop les problemes de gestion de memoire qu'il peut avoir c'est pour
ca que je te parle des autres problemes potentiels dans tomcat, un
expert te repondra sans doute popur hibernate,
Et je t'accorde que le profiling/debogage de Tomcat a chaud demande un
peu d'experience :-) (enfin surtout pour mettre le bon classpath apres
tout ;-)
J'aimerais savoir comment se comportent les variables statiques lorsqu'on recharge un contexte (dans tomcat par ex.).
Imaginons que j'ai une classe A :
Code:
public class A { private static Integer[] staticMember;
static { staticMember = new Integer[100]; for ( int i = 0; i < staticMember.length; i++ ) { staticMember[i] = new Integer(i); } } ...
Est-ce que le contenu du tableau sera effacé lorsque le contexte sera rechargé ?
Le problème, c'est que j'ai sans arrêt des OutOfMemoryError dans Tomcat avec Hibernate et il me semble qu'à chaque fois que je redémarre mon contexte, la configuration est rechargée en mémoire et au bout de cinq ou six fois je suis à 120MB et ça plante :-(
Merci d'avance Lilian
Une supposition: est que la classe A ne serait pas
serializee/deserializee quand tu recharge le contexte, et comme tu cree sans doute une nouvelle session pour retester les sessions precendentes occupent encore de la place en memoire. Tu as verifie le nombre de sessions ouvertes ? (detrompez moi)
Sinon un des memory leak de tomcat (enfin de javac) est la recompilation des jsps. C'est pour ca que pour avoir une applis "pro" sans fuite de memoire, et avec de bien meilleures performances (detrompez moi), en general on precompile ses jsps (ca interdit de les modifier a chaud mais bon en production on touche pas trop les applis normalement).
D'un autre cote comme je ne connais hibernate qu'en surface je n'imagine pas trop les problemes de gestion de memoire qu'il peut avoir c'est pour ca que je te parle des autres problemes potentiels dans tomcat, un expert te repondra sans doute popur hibernate,
Et je t'accorde que le profiling/debogage de Tomcat a chaud demande un peu d'experience :-) (enfin surtout pour mettre le bon classpath apres tout ;-)
J'aimerais savoir comment se comportent les variables statiques lorsqu'on recharge un contexte (dans tomcat par ex.).
Imaginons que j'ai une classe A :
Code:
public class A { private static Integer[] staticMember;
static { staticMember = new Integer[100]; for ( int i = 0; i < staticMember.length; i++ ) { staticMember[i] = new Integer(i); } } ...
Est-ce que le contenu du tableau sera effacé lorsque le contexte sera rechargé ?
Le problème, c'est que j'ai sans arrêt des OutOfMemoryError dans Tomcat avec Hibernate et il me semble qu'à chaque fois que je redémarre mon contexte, la configuration est rechargée en mémoire et au bout de cinq ou six fois je suis à 120MB et ça plante :-(
Merci d'avance Lilian
Une supposition: est que la classe A ne serait pas
serializee/deserializee quand tu recharge le contexte, et comme tu cree sans doute une nouvelle session pour retester les sessions precendentes occupent encore de la place en memoire. Tu as verifie le nombre de sessions ouvertes ? (detrompez moi) Si c'est tu rentres dans ce cas de figure marque tes champs comme transient (et les recharger quand le besoin se presente) te fera economiser de la ram.
Sinon un des memory leak de tomcat (enfin de javac) est la recompilation des jsps. C'est pour ca que pour avoir une applis "pro" sans fuite de memoire, et avec de bien meilleures performances (detrompez moi), en general on precompile ses jsps (ca interdit de les modifier a chaud mais bon en production on touche pas trop les applis normalement).
D'un autre cote comme je ne connais hibernate qu'en surface je n'imagine pas trop les problemes de gestion de memoire qu'il peut avoir c'est pour ca que je te parle des autres problemes potentiels dans tomcat, un expert te repondra sans doute popur hibernate,
Et je t'accorde que le profiling/debogage de Tomcat a chaud demande un peu d'experience :-) (enfin surtout pour mettre le bon classpath apres tout ;-)
J'aimerais savoir comment se comportent les variables statiques lorsqu'on
recharge un contexte (dans tomcat par ex.).
Imaginons que j'ai une classe A :
Code:
public class A
{
private static Integer[] staticMember;
static
{
staticMember = new Integer[100];
for ( int i = 0; i < staticMember.length; i++ )
{
staticMember[i] = new Integer(i);
}
}
...
Est-ce que le contenu du tableau sera effacé lorsque le contexte sera
rechargé ?
Le problème, c'est que j'ai sans arrêt des OutOfMemoryError dans Tomcat avec
Hibernate et il me semble qu'à chaque fois que je redémarre mon contexte, la
configuration est rechargée en mémoire et au bout de cinq ou six fois je
suis à 120MB et ça plante :-(
Merci d'avance
Lilian
Une supposition: est que la classe A ne serait pas
serializee/deserializee quand tu recharge le contexte, et comme tu cree
sans doute une nouvelle session pour retester les sessions precendentes
occupent encore de la place en memoire. Tu as verifie le nombre de
sessions ouvertes ? (detrompez moi) Si c'est tu rentres dans ce cas de
figure marque tes champs comme transient (et les recharger quand le
besoin se presente) te fera economiser de la ram.
Sinon un des memory leak de tomcat (enfin de javac) est la recompilation
des jsps. C'est pour ca que pour avoir une applis "pro" sans fuite de
memoire, et avec de bien meilleures performances (detrompez moi), en
general on precompile ses jsps (ca interdit de les modifier a chaud mais
bon en production on touche pas trop les applis normalement).
D'un autre cote comme je ne connais hibernate qu'en surface je n'imagine
pas trop les problemes de gestion de memoire qu'il peut avoir c'est pour
ca que je te parle des autres problemes potentiels dans tomcat, un
expert te repondra sans doute popur hibernate,
Et je t'accorde que le profiling/debogage de Tomcat a chaud demande un
peu d'experience :-) (enfin surtout pour mettre le bon classpath apres
tout ;-)
J'aimerais savoir comment se comportent les variables statiques lorsqu'on recharge un contexte (dans tomcat par ex.).
Imaginons que j'ai une classe A :
Code:
public class A { private static Integer[] staticMember;
static { staticMember = new Integer[100]; for ( int i = 0; i < staticMember.length; i++ ) { staticMember[i] = new Integer(i); } } ...
Est-ce que le contenu du tableau sera effacé lorsque le contexte sera rechargé ?
Le problème, c'est que j'ai sans arrêt des OutOfMemoryError dans Tomcat avec Hibernate et il me semble qu'à chaque fois que je redémarre mon contexte, la configuration est rechargée en mémoire et au bout de cinq ou six fois je suis à 120MB et ça plante :-(
Merci d'avance Lilian
Une supposition: est que la classe A ne serait pas
serializee/deserializee quand tu recharge le contexte, et comme tu cree sans doute une nouvelle session pour retester les sessions precendentes occupent encore de la place en memoire. Tu as verifie le nombre de sessions ouvertes ? (detrompez moi) Si c'est tu rentres dans ce cas de figure marque tes champs comme transient (et les recharger quand le besoin se presente) te fera economiser de la ram.
Sinon un des memory leak de tomcat (enfin de javac) est la recompilation des jsps. C'est pour ca que pour avoir une applis "pro" sans fuite de memoire, et avec de bien meilleures performances (detrompez moi), en general on precompile ses jsps (ca interdit de les modifier a chaud mais bon en production on touche pas trop les applis normalement).
D'un autre cote comme je ne connais hibernate qu'en surface je n'imagine pas trop les problemes de gestion de memoire qu'il peut avoir c'est pour ca que je te parle des autres problemes potentiels dans tomcat, un expert te repondra sans doute popur hibernate,
Et je t'accorde que le profiling/debogage de Tomcat a chaud demande un peu d'experience :-) (enfin surtout pour mettre le bon classpath apres tout ;-)
Une supposition: est que la classe A ne serait pas serializee/deserializee quand tu recharge le contexte, et comme tu cree sans doute une nouvelle session pour retester les sessions precendentes occupent encore de la place en memoire. Tu as verifie le nombre de sessions ouvertes ? (detrompez moi) Si c'est tu rentres dans ce cas de figure marque tes champs comme transient (et les recharger quand le besoin se presente) te fera economiser de la ram.
Le nombre de sessions ouvertes est toujours : 0 après que j'ai redémarré le contexte 1 dès que j'ai appelé une page au moins une fois
Sinon un des memory leak de tomcat (enfin de javac) est la recompilation des jsps. C'est pour ca que pour avoir une applis "pro" sans fuite de memoire, et avec de bien meilleures performances (detrompez moi), en general on precompile ses jsps (ca interdit de les modifier a chaud mais bon en production on touche pas trop les applis normalement).
Il m'arrive bien sur de modifier des jsps, auxquels cas elles sont recompilées mais en ce moment je bosse surtout sur des Objets et des fichiers de config Struts, c'est pour ça que je dois souvent redémarrer mon contexte et c'est ce qui consomme toujours plus de RAM.
D'un autre cote comme je ne connais hibernate qu'en surface je n'imagine pas trop les problemes de gestion de memoire qu'il peut avoir c'est pour ca que je te parle des autres problemes potentiels dans tomcat, un expert te repondra sans doute popur hibernate,
Je l'espère, mais ce que tu me dis me paraît tout à fait valable même si pour le moment ça n'a pas l'air d'être la source du problème.
Et je t'accorde que le profiling/debogage de Tomcat a chaud demande un peu d'experience :-) (enfin surtout pour mettre le bon classpath apres tout ;-)
Merci pour ton aide, bonne journée à toi aussi A+Lilian
Une supposition: est que la classe A ne serait pas
serializee/deserializee quand tu recharge le contexte, et comme tu cree
sans doute une nouvelle session pour retester les sessions precendentes
occupent encore de la place en memoire. Tu as verifie le nombre de
sessions ouvertes ? (detrompez moi) Si c'est tu rentres dans ce cas de
figure marque tes champs comme transient (et les recharger quand le besoin
se presente) te fera economiser de la ram.
Le nombre de sessions ouvertes est toujours :
0 après que j'ai redémarré le contexte
1 dès que j'ai appelé une page au moins une fois
Sinon un des memory leak de tomcat (enfin de javac) est la recompilation
des jsps. C'est pour ca que pour avoir une applis "pro" sans fuite de
memoire, et avec de bien meilleures performances (detrompez moi), en
general on precompile ses jsps (ca interdit de les modifier a chaud mais
bon en production on touche pas trop les applis normalement).
Il m'arrive bien sur de modifier des jsps, auxquels cas elles sont
recompilées mais en ce moment je bosse surtout sur des Objets et des
fichiers de config Struts, c'est pour ça que je dois souvent redémarrer mon
contexte et c'est ce qui consomme toujours plus de RAM.
D'un autre cote comme je ne connais hibernate qu'en surface je n'imagine
pas trop les problemes de gestion de memoire qu'il peut avoir c'est pour
ca que je te parle des autres problemes potentiels dans tomcat, un
expert te repondra sans doute popur hibernate,
Je l'espère, mais ce que tu me dis me paraît tout à fait valable même si
pour le moment ça n'a pas l'air d'être la source du problème.
Et je t'accorde que le profiling/debogage de Tomcat a chaud demande un
peu d'experience :-) (enfin surtout pour mettre le bon classpath apres
tout ;-)
Une supposition: est que la classe A ne serait pas serializee/deserializee quand tu recharge le contexte, et comme tu cree sans doute une nouvelle session pour retester les sessions precendentes occupent encore de la place en memoire. Tu as verifie le nombre de sessions ouvertes ? (detrompez moi) Si c'est tu rentres dans ce cas de figure marque tes champs comme transient (et les recharger quand le besoin se presente) te fera economiser de la ram.
Le nombre de sessions ouvertes est toujours : 0 après que j'ai redémarré le contexte 1 dès que j'ai appelé une page au moins une fois
Sinon un des memory leak de tomcat (enfin de javac) est la recompilation des jsps. C'est pour ca que pour avoir une applis "pro" sans fuite de memoire, et avec de bien meilleures performances (detrompez moi), en general on precompile ses jsps (ca interdit de les modifier a chaud mais bon en production on touche pas trop les applis normalement).
Il m'arrive bien sur de modifier des jsps, auxquels cas elles sont recompilées mais en ce moment je bosse surtout sur des Objets et des fichiers de config Struts, c'est pour ça que je dois souvent redémarrer mon contexte et c'est ce qui consomme toujours plus de RAM.
D'un autre cote comme je ne connais hibernate qu'en surface je n'imagine pas trop les problemes de gestion de memoire qu'il peut avoir c'est pour ca que je te parle des autres problemes potentiels dans tomcat, un expert te repondra sans doute popur hibernate,
Je l'espère, mais ce que tu me dis me paraît tout à fait valable même si pour le moment ça n'a pas l'air d'être la source du problème.
Et je t'accorde que le profiling/debogage de Tomcat a chaud demande un peu d'experience :-) (enfin surtout pour mettre le bon classpath apres tout ;-)
