Guillaume VIEL :: java jee tomcat linux

Aller au contenu | Aller au menu | Aller à la recherche

jeudi 8 juillet 2010

AVWorks , Java et IPv6

L'application AVWorks est une application fournie avec les KVM IP d'Avocent et notamment la série des Autoview. Ces anciens KVM IP ne fonctionnent qu'en IPv4. AVWorks est réalisée en Java et il semblerait que la façon dont Sun ait implémenté la dual stack IPv4 / IPv6 dans la JVM est plutôt étrange ( cf. article suivant sur debian et ipv6 )... Surprise donc lorsqu'en passant en dual stack IPv4 / IPv6 sur Debian je me retrouve avec l'application AVWorks et toutes les autres applications java qui ne marchent plus.

J'ai donc cherché à patcher l'application afin qu'elle refonctionne et c'est possible. Voici comment faire :

  1. surtout garder l'ancienne version 2.1 d'AVWorks et ne pas installer la nouvelle version 3.1 qui contient pas mal de bugs
  2. dans le fichier AVWORKS_HOME/Avocent_AVWorks.lax il suffit d'y ajouter la variable d'environnement java "java.net.preferIPv4Stack=true" vers la ligne 68 comme ceci: lax.nl.java.option.additional=-Djava.library.path=AVWORKS_HOME/Avocent_AVWorks -Duser.variant=avct -Djava.net.preferIPv4Stack=true
    (avec AVWORKS_HOME qui doit être remplacé par votre répertoire d'installation d'AVWorks)
Edit :
En fait, après enquête, il s'avère que le dysfonctionnement venait d'un problème plus général lié à la mise à jour de l'OS (i.e. une Debian)... Le paramètre noyau net.ipv6.bindv6only était à 1 !!! Ceci privilégie IPv6 avant tout, d'où les problèmes de java qui cherchait à se connecter en IPv6 avec des adresses IPv4. Pour remédier au problème il suffit de mettre net.ipv6.bindv6only=0 dans le fichier /etc/sysctl.d/bindv6only.conf et de lancer invoke-rc.d procps restart pour faire appliquer la nouvelle configuration.

Sources :

sun-java6-jre: net.ipv6.bindv6only=1 breaks java networking

net.ipv6.bindv6only=1 breaks java networking

ERROR: transport error 202: connect failed: Connection refused


mercredi 10 juin 2009

JVM 1.5.0_10 crash en mode remote debugging

Apparemment il est possible de faire crasher très simplement une JVM en mode debug. Je viens de le constater sur un serveur Tomcat qui était en mode debug (cf billet sur remote debugging tomcat) sur le port 8000, il suffit tout simplement de lancer une requête HTTP sur celui-ci pour faire planter la JVM :

ERROR: transport error 202: handshake failed - received >GET / HTTP/1.1< - excepted >JDWP-Handshake< ["transport.c",L41]
JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal error

Il est donc vivement conseillé de ne pas mettre vos serveurs en production en mode debug... On vous aura prévenu...

Le bug est connu http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6339385


mardi 18 mars 2008

Monitoring JVM Sun avec jvmstat et VisualGC

Sun propose quelques outils pour monitorer la JVM : jstatd, jvmstat et visualGC. Cela reste rudimentaire par rapport à d'autres outils comme jconsole mais cela a le mérite d'exister! Le principal intérêt d'utiliser encore cet outil est qu'il fonctionne pour les vieilles JVM version 1.4! Cet outil n'est pas packagé directement dans le JDK. Voici comment mettre en place cette techno rapidement en Java 1.4, Java 5 ou Java 6 entre une machine linux sur laquelle réside l'application java à monitorer et un poste de travail windows ou linux

Lire la suite...