HOAB

Problème :

Faire des threadumps un peu assisté pour Java sous Windows. Normalement, il faut :

• repérer le pid
• appeler jstack sur le pid
• stocker le résultat dans un fichier unique

Mais j'avais besoin d'un script oneshot que les utilisateurs puissent lancer facilement et plusieurs fois

Solution :

Merci aux différentes ressources du net, voici un petit script rapide :

@echo off

SET JAVA_HOME=c:\Program Files\Java\jdk1.7.0_51\
SET OUTPUT_DIR=c:\temp\lzg_threaddumps
SET COMMAND_TO_CHECK=java.exe

setlocal enableextensions
if not exist "%OUTPUT_DIR%" md "%OUTPUT_DIR%"
endlocal

for /f "tokens=2" %%F in ('tasklist /nh /fi "imagename eq %COMMAND_TO_CHECK%"') do (


    SET DEST_FILE="%OUTPUT_DIR%\%%F_%date:~-4,4%%date:~-7,2%%date:~-10,2%_%time:~-11,2%%time:~-8,2%%time:~-5,2%%time:~-2,2%.txt"
    @echo Dumping %%F to file %DEST_FILE%
    rem echo "%JAVA_HOME%\bin\jstack.exe" %%F
    "%JAVA_HOME%\bin\jstack.exe" %%F > %DEST_FILE%
)

Problem :

I have two thread groups that must be synchronized. I want to use

java.util.concurrent.CountDownLatch

to achieve this.

I read (here, or here) how to synchronize JMeter thread groups (you have to use properties and not variables). Properties can be access in :

• bsh sampler : bsh.shared.<property name>
• jsr223 sample : props.put(<property name>)
• the org/apache/jmeter/util/JMeterUtils.class is the source of these properties.

I add to my test plan an initial element in bsh, jsr223 to create the latch. But when I get the latch in the thread groups, I always had different instance of my shared latch.

Solution :

Easy when we know.

I made the mistake to add the piece of code in a Pre-Processor

• Test Plan
  • PreProcessor BSH : init latch
  • Thread Group 1
    • Sampler BSH : wait for latch
  • Thread Group 2
    • Sampler BSH : count down latch

In this case, the PreProcessor is run before each thread initialization. I run X times the preprocess sample.

Correct test plan :

• Test Plan
  • Set up Thread Group
    • Sampler BSH : init latch
  • Thread Group 1
    • Sampler BSH : wait for latch
  • Thread Group 2
    • Sampler BSH : count down latch

The setup Thread Group is run before the others thread groups (these ones are parallel until you say not to do)

Le problème :

I know that many post have been written on the subject, but has I do not had a quick solution. Here is some few more information.

When connecting to webex from Linux, I had no sharing.

Solution :

First I used Firefox 64 and JVM 64. It doesn't work. Whatever I read on the net (from this link, or there).

So :

1. Install i386 architecture
2. install firefox32 (< 52.x otherwise Java is not working for now)
3. create a separate profile
4. install missing packages... (when starting firefox32)
5. install 32bits JVM
6. create a link to the JVM plugin in the new profile
7. remove any shared plugin (for example JVM 64bits plugin in shared plugins library) : use plugins directory in profile

This is a quick & dirty, I'll try to update it after.

Useful tips :

• about:plugins in firefox
  • if the 32bits plugins is not there, or the JVM64 is still there, don't go further, correct this
• http://java.com/verify/
• remove webex directory : ~/.webex
• install missing packages for webex (ldd tips)
• sometimes it can be long when you are behind a proxy

Le problème :

I follow the integration guide from JetBrains :

• Integrate JBoss and Intellij
• Deploying application to Application Server

But I deploy my application (that use EJB), EJB (referenced by @EJB and defined in ejb-jar.xml) were not found

Solution :

After a few tests, I found that JBoss require that a deployment directory must finished with a known extension

JBAS015010: Le scanner de déploiement a trouvé un répertoire nommé META-INF qui n'était pas à l'intérieur d'un répertoire dont le nom se termine par .ear, .jar, .rar, .sar ou .war.

So when I modify the output dir of the artifact deployed to jboss from "mywebapp" to "mywebapp.war", it works...

Le problème :

J'ai des VM imposantes de 45Go à 100Go (ne me demandez pas pourquoi, c'est une contrainte externe...). Je les utilisais localement sous Virtualbox.

J'utilisais Virtualbox car celui-ci s'intégre mieux à mon Linux que VMWare qui nécessitait une recompilation avec une version GCC obsolète, un peu galère.

Les VM ont été transférées par l'hébergeur directement sur l'ESXi sur l'espace de stockage, au format OVA.

Le problème a été lors du déploiement de ces OVA en local sur l'ESXi, je devrais dire LES problèmes....

Solution :

Cela a été un peu long car je ne connaissais rien à VCenter (le manager de ESXi).

D'abord il faut savoir que c'est un OS, donc pas d'accès SSH pour aller voir ce qui se passe (enfin, voir la suite, ce n'est pas tout à fait vrai !)

1) Déployer OVA depuis le local store de l'ESXi

Bon ce n'est pas possible. Le client demande une URL et pas un chemin "local"

2) Webbrowser du local store (ne marche pas)

Malin le singe ! Le local store a un webbrowser : http://<ip esxi>/folder/ (d'ailleurs décrit ici par exemple)
Donc on redémarre le déploiement en indiquant une adresse en

http://172.16.29.100/folder/test/toto.ova?dcPath=ha%2ddatacenter&dsName=data

Le problème ici est que vu la taille des VM ou le serveur HTTP associé, on obtient au bout de quelques temps une erreur 503.

3) Format OVA Virtualbox non supporté

Alors avant de tomber sur l'erreur 503, VSphere a eu le temps d'analyser l'OVA pour indiquer que :

- le system est inconnu (normal virtualbox) : remplacer par vmware
- l'interface disque est inconnue (normal SATA alors que SCSI sur le serveur) : remplacer par du SCSI
- la carte son est inconnue (normal aussi, le serveur n'a pas le temps de jouer de la musique)i : supprimer la section

Pour corriger ça, c'est simple, c'est décrit à plusieurs endroits (ici, là) : il faut modifier l'OVF. Rappel dans l'OVA il y a un disque un VMDK + un descripteur l'OVF.

Donc modifier l'OVF. Qui est sur l'ESXi. Dans un OVA que je ne peux pas télécharger et uploader car trop gros. Easy (décrit ici):

1. ouvrir l'accès SSH VSphere pour un utilisateur,
2. transférer 7z portable,
3. dézipper l'OVA avec 7z
4. modifier le fichier OVF.

Petite astuce pour savoir où sont stocké les VMDK / OVA :

1. accès SSH
2. find . -name "*ova"

4) Recréer une VM à partir du VMDK (ne marche pas)

J'ai essayé de créer une nouvelle VM vierge en utilisant un disque VMDK existant.

Outre le fait qu'on ne peut sélectionner le VMDK que si un descripteur VMDK est recréé (méthode ici) au final la VM ne démarre pas. Un boot avec une iso GParted montre un disque vide. Le descripteur VMDK ne doit pas être correct pourtant monsieur ! je jure ! j'ai tout fait comme il faut !

5) Déploiement final

L'OVF est modifié, il reste à avoir un serveur HTTP digne de ce nom pour servir l'image au VCenter.

Sur le serveur j'avais déjà une VM existante... Donc :

1. on transfère l'OVF et le VMDK sur la VM existante
2. qui est trop petite, donc on l'agrandit avec un disque supplémentaire
3. on créé les volume group, logical volum et filesystem sous linux
4. on retransfère l'OVF et le VMDK dans un répertoire qui a de la place
5. on démarre un serveur python dans ce répertoire :

python -m SimpleHTTPServer

6. dans le vClient on donne l'adresse IP de la VM : http://<ip VM>:8000/monfichier.ovf
7. et ça déploie.... pas. Enfin si mais lentement. Parce que même si la VM et l'ESXi sont dans le même sous réseau on passe par le poste du vClient... en ADSL...
8. donc nouvelle VM (ou la même) : installation du vClient dans le même sous réseau et on utilise le vClient dans le même sous réseau

VICTORY.... Argh.... ça été dur.