Problème :
J'ai une configuration un peu particulière :
- je développe et teste majoritairement sous Linux, Ubuntu
- pour certains cas, je lance une VM Windows 10 sous virtualbox pour tester IE/Edge
Je lance comme d'habitude mon application, j'essaie de m'y connecter depuis la VM impossible...
Configuration de la VM :
- en NAT
- en virtual network
Solution :
Evidemment je pense au paramètre `server.address` de Spring boot car j'ai un log qui m'affiche : Listening on 127.0.0.1:8080
Mais ça ne marche pas...
Je tente X configurations différentes : dans le fichier de configuration, en paramètre avec le -Dserver.address
Je tente avec le port forwarding NAT de Virtualbox. Nada.
La connexion SSH fonctionne : je peux me connecter depuis la VM
Je vérifie le firewall, pas activé.
Jé vérifie IPTables, ça me semble OK
Le netstat a du mal à sortir les LISTEN, j'utilise : lsof -i -P -n | grep LISTEN
Et là :
1) Springboot écoute bien par défaut sur toutes les IPv4, comme décrit a plein d'endroit, le server.address fonctionne très bien
2) le log affiché était applicatif et codé en dur : argh :(
3) c'était le iptable qui bloquait... il fallait regarder le FORWARD et pas le INPUT... pas sur d'avoir compris pourquoi, a priori on ne change pas de réseau/machine. A creuser. Commande iptable pour ouvrir le port.
Problem :
I used robertdebock/ansible-role-tomcat to install a Tomcat instance using Ansible. Works well until I deploy an application on it. Then java process hangs with 100% system CPU.
Starting with tomcat users without system work correctly.
Solution :
I suspected :
- SELinux
- Linux limits
- VM slow I/O
But after a while I ran strace :
- by modifying systemd configuration
- by modifying catalina.sh configuration
All I have was a simple FUTEX wait...
And then I read the manual, as simple as :
strace -f -e trace=all -p <PID>
No need to trace from startup and by default, not all is traced...
After that, easy way, the process was reading recursively :
/proc/self/task/81569/cwd/proc/self/task/81569/cwd/proc/self/task/81569/cwd/proc/self/task/81569/cwd/proc/self/task/81569/cwd/proc/self/task/8156...
Just fixing the working_directory in the ansible role, and all is working.
Issue reported here.
Le problème :
Avec une stack JHipster, spring-boot n'affiche pas les ressources statiques en mode développement.
Ddonc par exemple pas de index.html...
Pour autant si on lance la commande avec le war serverless (cf spring-boot-maven-plugin), ça fonctionne.
Je suis sous Intellij, à l'évidence quelque chose manque dans le lancement de la tâche Intellij spring-boot
L'architecture est mavenisé donc le root contexte est sous : src/main/webapp
Cependant spring-boot semble chercher ses ressources ailleurs : cf la documentation
Par quelle magie spring-boot doit-il trouver ses ressources dans src/main/webapp ??
Solution :
Beaucoup de recherches, de debug et autre (il y a un peu de spring-secu dans le lot). Au final les services jhipster classiques (health, dump, etc...) fonctionnent mais toujours pas de ressources statiques.
Vérification :
- de la tâche de lancement Intellij, elle semble correcte.
- des classpaths (on met src/main/webapp dans le classpath, on l'enlève)
- des paramètres de lancement (profil Spring et autre)
Au final la mise en debug m'a permis de trouver un log perdu parmi les autres :
[DEBUG] org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory - None of the document roots [src/main/webapp, public, static] point to a directory and will be ignored.
Tiens donc le Tomcat embarqué de spring-boot a ses propres chemins de recherches... (pas tout à fait décrit dans la doc Spring ci-dessus).
Breakpoint, watch, et paf, le chemin vers src/main/webapp en absolu n'est pas le bon.
Tout ça parce que le répertoire de travail de ma tâche spring-boot sous Intellij n'était pas fixé. Comment Intellij détermine cette valeur ? Mystère. En mettant donc le répertoire de travail égal au répertoire qui contient le src/main/webapp, tout roule (ici le répertoire de travail serait : /home/user/projets/monprojet/webportal.
On retrouve le log :
[DEBUG] org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory - Document root: /home/user/projets/monprojet/webportal/src/main/webapp
Eclairé aussi par ce lien
Le problème :
Connecter Yourkit à un Tomcat installé localement sur une machine Windows
Tomcat exécuté en tant que service avec le profil Administrateur
Solution :
Bon rappel de ce qui est décrit ici
-
Tomcat5 : installation / désintallation du service
-
Tomcat5w : fenetre de contrôle du service et de ses paramètres
Il faut donc exécuter ces programmes dans une console en ligne de commande "admin" :
# Démarrer
# Exécuter...
cmd
# Valider avec : "Ctrl + Shift + Enter"
Sinon, on peut toujours faire bouton droit sur Tomcat5w et "exécuter en tant qu'Administrateur".
Ensuite, ajouter le lien vers l'agent Yourkit :
-
Il faut mettre les chemins courts de Windows !
-
De cette manière :
# Nom court sous windows :
dir /x c:\
# Pour obtenir au final le chemin complet :
dir C:\PROGRA~2\YOURKI~1.6\bin\win32\yjpagent.dll
Ajouter le chemin aux paramètres de la JVM du service Tomcat :ourkit
-agentpath:C:\PROGRA~2\YOURKI~1.6\bin\win32\yjpagent.dll
Et ne pas oublier de démarrer Yourkit en mode Administrateur.