Java Tech Tips & Tutorials

Dans quels cas le thread dump est utile ? Le thread dump est un instantané de l'activité des threads de la JVM. Leur analyse est intéressante dans les cas où l'activité de la JVM ne semble pas normale : Activité suspendue (deadlock/ interblocage ) ou partiellement suspendue (starvation/ famine ) Activité existante mais le "débit" est en deçà de ce qui est attendu (Goulot d'étranglement / Bottleneck) Activité existante mais le "débit" reste nul (Boucle infinie / Infinite Loop) Comment avoir un thread dump ? Nous nous limitons ici à la machine virtuel IBM sous AIX. Dans ce cas là il est extrêmement simple de déclencher la création d'un thread dump : il suffit de faire un kill -3 sur le processus Java. Un fichier dont le nom est javacore. [date] . [numero_processus] . [compteur] .txt est produit. Sur la sortie standard du processus vous devriez voir la ligne suivante s'afficher : JVMDUMP010I Java Dump written to ..... En général le dump ...

Ou « Combien de messages JMS un serveur JMS peut-t-il emmagasiner ? » Sous Weblogic (je ne sais pas comment cela se passe avec les autres) tout message JMS est stocké au moins partiellement dans la mémoire de la JVM, et cette mémoire n'étant pas infinie l'arrivée d'un grand nombre de messages associée à une mauvaise configuration du sous système JMS se solde souvent par un OutOfMemory. Le schéma ci dessous montrent les différents mécanismes qui peuvent être mis œuvre par un serveur JMS afin de gérer l'accumulation des messages JMS et de réguler leur arrivée. 1. Définir un quota Un message JMS consomme toujours de la mémoire . Partant de ce postulat un quota devrait toujours être défini sur un serveur JMS. Il évitera une saturation mémoire en refusant aux producteurs de poster des nouveaux messages lorsque le quota est atteint. Les quotas peuvent être définis au niveau des modules JMS, cependant il peut être plus "sécurisant" de les placer directement au n...

Avant propos : Le contenu de ce billet valable à partir de Java 5 Pour pouvoir tester les exemples présentés dans ce billet vous devez avoir correctement installé l' "Agent Controller" du projet Eclipse TPTP comme cela est décrit ici . Si les notions d' "Agent" et d' "Agent Controller" ne vous disent rien vous pouvez vous rendre ici . Performances, données et outils Une séance de "profiling" peut très vite se trouver ralentie. Ce phénomène a en règle générale deux origines : La quantité de données collectées par l'outil, à plus forte raison si il s'agit d'une session distante ("Agent" sur une machine, client sur une autre) . Les performances de l'outil qui va analyser et restituer ces données, si l'interface graphique fournie par Eclipse TPTP est très fournie il n'en reste pas moins que si la quantité de données à digérer est trop importante votre système pourrait ne plus répondre. Séri...

It seems that the Eclipse TPTP project has stopped to provide Agent Controller and agent libraries for some Unix platforms like IBM AIX. I have just tried to use the IBM Rational Agent Controller (available at http://www-01.ibm.com/support/docview.wss?rs=2042&uid=swg27013420 ) with Eclipse TPTP 4.7.1 as client. Surprisingly it seems to be perfectly compatible, i have successfully collected profiling data on an Eclipse Workbench under Windows from a IBM J9 32bits VM SR8 running on a 64bits IBM AIX PowerPC 6. Some tips : While i tried to profile with an Xmx value equals or greater than 2048m the JVM crashed   with the following error as soon as i attached the Eclipse Workbench to the Agent Controller: Unhandled exception Type=Illegal instruction vmState=0x00000000 J9Generic_Signal_Number=00000010 Signal_Number=00000004 Error_Value=00000000 Signal_Code=0000001e ….. Target=2_40_20100401_055940 (AIX 5.3) CPU=ppc (4 logical CPUs) (0x200000000 RAM) ----------- Stack B...

N.B. : Les informations présentées ici ne sont valables qu'à partir de la version 5.0 de Java Suite à un premier billet sur le mise en place de l'Agent Controller du projet TPTP en voici un autre pour décrire un peu plus précisément son architecture. Au premier abord il n'est en effet pas évident de s'y retrouver entre les éléments mis en jeu. Vue d'ensemble de l'architecture L'architecture de TPTP est organisée autour de 3 éléments : L' Agent : il s'agit d'un programme qui s’exécute dans le même processus que la JVM. Il est notifié des évènements internes au travers de la JVM Tool Interface (JVMTI). JVMTI est une interface qui permet de connaître l'état de la JVM et de contrôler de manière avancée l'exécution des applications Java qui y sont exécutées. L' Agent Controller : Il s'agit d'un programme qui doit résider sur la même machine que la JVM. Il gère tout le processus de démarrage et de communication avec l...

C'est en général une fois l'application développée que les questions de performance surgissent : temps de traitement et de réponse en dessous des espérances ou encore consommation mémoire élevée avec un "garbage collector" qui peine à faire son travail sans trop pénaliser l'applicatif. La complexité des piles Java actuelles n'aidant pas forcément à y voir plus clair on peut se retrouver vite désarmé lorsqu'il s'agit d'expliquer une consommation inhabituelle des ressources ou des temps d'attente anormaux. Ayant fait face à plusieurs reprises à ce genre de situations j'ai décidé d'écrire une série de billets sur la recherche  et la détection de ces "goulots" qui pénalisent les performances d'un application. Avant de pouvoir profiter pleinement des possibilités offertes par TPTP ce billet a pour objectif de présenter comment installer de manière propre l'Agent Controller (appelé AC par la suite). L'Agent Controll...