Reprise du message précédent :
oui mais tu comptes quoi ?
parceque le problème il est là
je sais pas comment savoir à quel thread correspond quelle application
 
j'ai néamoins pour l'application qui m'intéresse réussit à le déterminer en voyant des classes d'un framework utilisé que par cette appli qui étaient attachés au thread
 
mais on pourrait rêver mieux

c'est pour ça qu'il n'y a aucun outil (du moins, que je connaisse).
 
il faut tracer en bas niveau pour connaître le thread-id de ta session (genre mot-clé dans une variable que tu traces)
 
mais après, pour calculer le "poids" de la heap de ce thread, à part naviguer dans le heap dump...
 
tiens, tu as jeté un oeil sur les outils genre jhat, jmap, ... présent dans ton JDK ?

pour calculer le poids du thread il y a pas de soucis avec un heap dump ouvert avec MAT  

ah oui c'est vrai (je ne l'utilise pas souvent )

Halp /o\
 
J'ai une librairie tierce (JBPM pour ne pas la nommer) qui contient un ClassLoader custom qui s'accumule en mémoire. J'y connais pas grand chose en classLoaders, mais en gros sur un certain nombre d'appels de méthodes de cette librairie, on a un truc genre:
 

Thread.currentThread().setContextClassLoader(new ProcessClassLoader(...));

 
Dans le monitoring de la jvm, on observe que des milliers d'instances de cet objet ProccessClassLoader() s'accumulent jour après jour.
Si je comprends bien la doc, ça peut sembler logique, les objets gardant une ref sur leur classloader (encore que, ces objets là sont censer mourir aussi, enfin bon).
 
Par contre, est-ce normal de faire un new à chaque fois? La classe contient des infos contextuelles mais je pourrai me limiter à une 15aine d'instance.
 
Toute remarque est la bienvenue, je sais meme pas si ce que je raconte a du sens.

 
Je connais pas la lib, mais j'ai la même intuition que toi. J'aurais vu un classloader isolé pour JBPM plutôt que chaque process, mais en wikipédiant j'ai vu que c'était pas franchement un truc de clampins sur sourceforge, donc y'a certainement une bonne raison.
 
T'oublies pas un close ou assimilé quelque part pour que les références subsistent ? C'est pas plutôt un problème de cycle de vie de tes objets ?
 

Pas un truc de clampins c'est à dire?
 
En gros chaque fois qu'on veut interagir avec la lib on fait un truc genre:

JbpmContext jbpmContext = JbpmConfig.get().createJbpmContext();
jbpmContext.loadProcessInstance(id);
// do stuff
jbpmContext.close()

 
Au niveau des close on est bon, d'un point de vue du user. Après c'est une lib genre mouton à 5 pattes dans une version obsolète donc que ça chie coté lib ne me surprendrait pas. Je penche plutot pour un problème de cycle de vie des ClassLoaders custom de la lib.

 
Pas un projet bancal en pré-beta maintenu par 0.5 user dont le dernier commit date de 2009 quoi.
Ceci dit, JBoss est pas nécessairement un gage de qualité, loin de là
 
Si vous êtes propres de votre côté, effectivement, ça commence à puer. J'imagine que t'as déjà regardé au niveau des tickets ouverts pour ta version ?

Est-ce que tu peux nous en dire plus ? à quoi te sert ton JBPM exactement ?
 
si tu charge des BPML avec, il y a peut-être appel à une fonction de calcul pourrie dans l'une des activités dans les BPML.
 
As-tu la possibilité faire le test sans rien faire avec JBPM ou seulement des BPML hyper bas niveau genre écrire HelloWorld sur un fichier ?

Oui j'ai regardé, un ticket a vaguement un rapport mais il concerne la version 4 alors que nous on est en 3.2 et que la version courante c'est la 5

C'est un moteur de workflow, on s'en sert pour modéliser des process métier. Si un traitement métier n'aboutie pas on le sait tout de suite. Mais bon les classloaders jbpm ne sont jamais manipulés en dehors de la lib.  
 
Là j'ai écris une factory custom pour remplacer celle qui instancie les classloaders en question et je vais tester, voir ce que ça donne.

Thread.currentThread().setContextClassLoader(new ProcessClassLoader(...));

C'est manifestement un bug, soit de la lib, soit dans ton utilisation de JBPM. L'instanciation d'un classloader peut s'expliquer par le fait que JBPM est un orchestrateur de processus indépendants. Donc comme tu le dis toi-même, si tu à 15 processus indépendants, tu devrais en toute logique avoir au max 15 classloaders, un classloader étant instancié au démarrage de chaque processus.

L'utilisation qu'on fait de la lib a été auditée l'an dernier par un expert donc ça irait de ce coté là.
J'ai la possibilité de lui filer une autre implem de la factory qui créé les classLoaders, aujourd'hui on va tester si tout fonctionne bien et sans fuites avec un nombre fixe de classloaders.

bonjour les gens,
 
pour du message queuing hi-speed avec une persistence digne de ce nom, vous utiliseriez quoi ? (middleware java sur du linux mais avec des satellites win/aix)
 
Les volumes sont disparates mais à 99% des petits fichiers texte (qques Ko) et en nb de fichiers c'est par vagues entre 100 et (15K avec des pics en cas de panne à 500K fichiers en attente)
 
on a du MQSeries pour l'arme atomique mais on cherche une solution open, simple, rapide et sans costumes 3 pièces bleu marine.
 
z'auriez quoi en vue ? (je zieute 0MQ et RabbitMQ)

petals est rapide, scalable, mais il faut quand meme réfléchir à son déploiement

0MQ = 0 persistence -> niet.
 
fiscalisator> je vais jeter un oeil, merci.

Regardes Redis sinon, tu peux l'utiliser comme une queue et c'est persisté.

mon prototype utilise déjà Redis avec key->list, avec AOF et save; ça marche plutôt bien.
facilement monitorable, clusterisable (v2.6), master/slave, ... et le développeur réagit au 1/4 de tour.
il me reste à jeter un oeil sur Sentinel.

j'adore cet outil

note pour le Windows, Redis n'est pas supporté malgré un portage de la v2.4; ce n'est pas grave dans mon cas.

fiscalisator> Petals est un ESB complet, un poil trop gras pour mon besoin

Quelqu'un a déjà fais joujou avec http://www.appdynamics.com/ ?
 
Sinon un petit retour sur ce genre d'outil, dynatrace et autre? On voudrait s'outiller dans un futur proche (monitoring custom pour l'instant).

ça a l'air sympa, je vais creuser l'affaire car le mien n'avance pas assez vite à mon goût.
 

monitoring custom de quoi ? java only ? monitoring live 24/7 ou à la demande ?

Petite question :  
 
 
JDK 8 avec les Lambda, c'est disponible où ?
 
D'après un page wiki d'oracle ( https://wikis.oracle.com/display/OpenJDK/JDK+8 )
Lambda + java 8 est disponible dans le jdk 8 car ça a été mergé. (donc normalement dispo ici : http://jdk8.java.net/download.html )
 
Or, dans ce JDK, je n'ai pas List#forEach, List#sort, etc.
 
Pour cela, je dois télécharger le JDK par ici http://jdk8.java.net/lambda/ qui...est un OpenJDK 7 + Lambda !
(Mais moi, j'aimerais bien les deux pour faire joujou avec les labmdas et la suppression du PermGem dans la HotSpot et là, ça ne dois pas être possible)
 
 
En parlant de PermGem, si je veux la faire peter, je pensais faire une boucle et dedans une définition de class
 

while(true) {
    class MyPredicate {
           // blabla
    }
    MyPredicate truc = new MyPredicate();
}

 
 
Question : je suppose que le compilateur va optimiser mon code et faire en sorte d'utiliser toujours la même définition de class ou il sera assez con pour créé à chaque fois une nouvelle instance de définition de class, qu'il ira gentiment mettre dans ma PermGem à chaque fois ?

Pour ta question, cela n'a pas grand chose à voir avec le compilateur. La définiton de la classe n'existe jamais qu'une seule fois. Au mieux tu peux réduire sa visibilité (et si je m'abuse, pas à un niveau plus fin que celui d'une méthode).  
Par contre, si tu avais fais une classe anonyme, là, ca devrait faire sauter la permgem.

On a une appli maison qui poll nos jvms et envoie des alertes par mail selon certains critères mais c'est tout, pas de profiling ni autre.

J'ai un repo central Maven. Il est sous Nexus, mais si la réponse à cette question pas encore posée est un outil qui tape dans un repo local sur un filesystem, ça m'ira déjà pas mal.
 
Je veux connaitre les projets (idéalement filtrer le scope de recherche par package) qui ont 'toto' dans leurs dépendances (idéalement pouvoir inclure / exclure les transitives).
Si on peut spécifier une version pour toto, voir une range, c'est le bonheur absolu.
 
Usage typique : une API maison, un bug sur l'API. L'API est utilisée par un bazilion de projets interne, si bien qu'après le bugfix, on ne sait pas quels projets sont impactés et corrigés. Je vous fait pas un dessin pour l'utilité de la version / range dans ce cas.

y'a pas justement un truc dans les versions récentes de Nexus pour ça ? (genre 2.0+)

Je suis en 2.0.3 et je vois rien qui s'en approche.
Je vais regarder les changelogs, mais du coup, j'ai une impression de déjà vu, je me demande si j'ai pas posé la même question ici  

Edit : ça ressemblerait à "View component dependencies" et "Search by custom metadata", mais les features sont dispos sur la version pro, on est en OSS.

Du coup, si un outil quelconque peut faire ça à partir d'un repo local, on va dire que ça fera l'affaire, j'ai pas le budget pour un Nexus pro et surtout pas à ce tarif pour une feature optionnelle.

et encore, c'est pas dit, vu que toi tu veux les dépendances "inverses" …
 
je me demande si j'avais pas un bout de code qui tentait de faire ça en fait … prfff

 
Bin si entre deux nettoyages ratés de workspace tu retrouves ça, je suis preneur
 
C'est quand même curieux de rien trouver sur l'intarweb là dessus. Ça me parait pas spécialement complexe à développer, et surtout relativement utile pour beaucoup de monde.
Je suis à côté de la plaque sur le besoin, j'utilise pas les bon keywords pour mes recherches ?
 

avec un grep bien senti dans tous les pom.xml que tu ramené de ton VCS ?

 
Voilà par exemple, ou sur le repo local, ou sur un distant si il est accessible au niveau FS / partage. Si je trouve rien et avec un peu de temps, je m'y collerais, mais ça m'étonne d'être le premier à éprouver ce besoin.

 
Un poil plus complexe si tu veux gérer les dépendances transitives. Je vois bien construction d'un arbre de dépendances durant le parsing et remontée de tous les nœuds parents pour les feuilles qui matchent le critère.

assez facile à faire ça... et maintenant qu'on cause d'arbre, je me demande si je n'ai pas vu ça dans NetBeans.
edit> il te faudrait ça en plus général: http://wiki.netbeans.org/NetBeans_ [...] cy_display

 
Oui, je pense que je torcherais un truc vite fais si je trouve rien.
L'option Netbeans que tu présentes à l'air de faire l'inverse, à savoir afficher l'arbre de dépendances d'un projet donné. La finalité de ce que je cherche est de trouver un projet selon des critères d'artéfacts, et d'en remonter tous les parents, i.e. les projets pour lesquels cet artéfact est une dépendance transitive.

LeRiton: Le coup du grep-ou-autre en local, ça va pas marcher, sauf si tu peux te contenter des dépendences directes. Et encore, il me semble que tu veux faire ça pour une version précise, donc t'es déjà baisé si la version est spécifiée dans un parent. Conclusion, il faudra parser et "résoudre" tous les poms que tu veux regarder... et leurs dépendences... ça va prendre un bout de temps Mais ça m'interesse aussi; j'ai remis les doigts sur un bout de code qui tente d'utiliser l'api Aether (c'est pas folichon)... si j'ai l'occase j'essaie d'en sortir un truc qui ait du sens et je te fais signe (mais il me semble me souvenir qu'il y avait un truc que je pigeais pas dans la résolution de deps que ça faisait)

Oui, j'en ai bien conscience, c'est un peu ce que j'évoquais avec

Si tu trouves pas c'est pas trop grave, j'ai commencé à bosser dessus, marre de chercher pour rien. Je vais tenter de sortir un proto qui tape dans un repo sur le filesystem dans un premier temps. Si c'est pas trop dégueu, je ferais tourner et je m'attaquerais aux connecteurs HTTP ou vers des API de repos type Nexus.

Pour le moment, j'utilise rien de l'écosystème Maven, c'est du parsing bête et méchant (et certainement très lent) des fichiers. Deux raisons : je veux tenter un premier jet rapide (i.e. sorti rapidement, pas performant) et je ne connais pas Aether ni de solutions approchante.

Je vous tiendrais au courant

Aether c'est la lib utilisée par maven3(je crois en tous cas) pour tout ce qui est résolution de dépendances (ça gère du coup aussi ton cache local, le download, etc). Et comme ils ont voulu pondre un truc indépendant de maven, c'est vraiment pas évident (parce quil faut reproduire un tas de trucs genre les settings maven...)

Sinon tas regardé sur mojo.codehaus.org ? Y'a ptet un plugin qui pourrait t'intéresser...

Non, j'ai pas cherché côté plugin pour le moment. Si je me trompe pas, tous les plugins s'exécutent sur un projet, donc je vais pas pouvoir lancer un traitement sur une grappe / un repo ?

ouais mais y'a des plugins genre pour la manip de ton repo/cache local (pour purger etc...) .. mais j'ai jeté un oeil, à priori y'a rien.
 
 

rien à voir,ça parle a qqun ça ?  

 
ça pue un problème d'initialisation, du genre tu colles un listener sur un objet qui est pas encore initialisé par exemple ...

Mouaif, j'aurais du virer la npe de la trace en fait, parce qu'à priori l'init est ok mais bon je vais tenter de retracer le bordel...

 
Fun fact #1: si comme moi, vous pensiez qu'un POM était toujours conforme à son schéma (à une vache près, je suis pas nazi), vous vous trompiez. Si vous pensiez qu'au minimum, c'était un XML valide, même chose.
C'est parti pour du parsing bien dégueu