Discussion :

[inflation]

Bonjour la communauté,

Je cherche à récupérer les références des thread qui ont été stoppés "status : stopped", dans mon cas, c'est une api qui les instancie, start et stop (DirContext dans JNDI) donc je n'ai aucune référence sur ces thread à fin de les mettre à null et inciter le GC à les virer de la mémoire

la méthode close() de la classe DirContext permet de fermer la connexion (socket), de stopper le thread et de le laisser en mémoire, et dans mon cas, le pool du JNDI n'étant pas activé, une connexion (via DirContext) est crée pour chaque requête.

J'ai fait monter en charge mon serveur (un webservice utilisant des connexions vers un LDAP) via l'outil SOAPUI, j'arrive à avoir plusieurs milliers de Thread en mémoire avec le statut "Stopped" donc morts et obsolètes, même s'ils ne consomment pas de CPU, j'aimerais les virer toute même de ma précieuse mémoire.

J'ai constaté via le debugger d'eclipse que l'objet DirContext contient une référence vers un objet LdapClient qui contient à son tour une référence vers un socket et le thread associé, mais je ne trouve aucun moyen public de récupérer ces informations pour exterminer le thread après le close().

J'espère que j'ai été un peu clair.

Par avance Merci pour votre aide.

inflation

[Logan Mauzaize]

Le principe du GC c'est qu'il passe quand il en a envie. En général, c'est soit pour récupérer des objets avec une durée de vie très courte (une méthode), soit quand la JVM a besoin de mémoire.

Est-ce que tu gardes des références sur le DirContext ?
Génères un heapdump avec "jvisualvm"

[inflation]

Bonjour Nemek,

Le principe du GC c'est qu'il passe quand il en a envie. En général, c'est soit pour récupérer des objets avec une durée de vie très courte (une méthode), soit quand la JVM a besoin de mémoire.

Est-ce que tu gardes des références sur le DirContext ?
Génères un heapdump avec "jvisualvm"

Je te remercie pour ta réponse,

Pour le DirContext, je le close en fin de requête via la méthode close() puis je le met à "null" juste au cas où

Pour la politique de la JVM, elle ne semble pas virer les thread mis à l'état "Stopped" et je pense qu'ils sont référencés quelque part

[inflation]

Génères un heapdump avec "jvisualvm"

Pardon, je viens juste de remarquer ça je vais creuser ça..thx

[Logan Mauzaize]

Les threads (stopped ou pas, comme tous les autres objets) sont libérables quand ils ne sont plus référencés. Tu peux également t'assurer qu'ils sont libérables en invoquant le Garbage Collector plusieurs fois via jvisualvm.

Après tu as des outils d'analyse plus poussé que jvisualvm (ex: MemoryAnalyzer).
Mais tu as au moins accès à la liste des objets qui ont une référence vers un objet qui t'interresse.
Il existe également un langage de requêtage (OQL) pour faire des recherches dans le dump.

[tchize_]

Les dircontext donc indirectement référencent le thread: ce sont donc les DirContext que tu dois arrêter de référencer -> regarder où est maintenue cette référence et la mettre à null dans ton code.

[Logan Mauzaize]

Pour le DirContext, je le close en fin de requête via la méthode close() puis je le met à "null" juste au cas où

Je sais je suis fou je lui fais confiance, je suis optimiste.
De toutes façons l'analyse du heapdump devrait lui dire s'il a loupé quelque chose de ce côté là.

[inflation]

Merci les gars, j'ai essayé mais j'ai eu d'autres soucis et je pense utiliser le pool du JNDI comme ça je serai tranquille.

Encore Merci.