397 liens privés
fail fast (return http status 503) pour éviter cpu starvation
via https://julien.mailleret.fr/links/?EEONow
Comment diagnostiquer un tomcat KO en analysant les thread dumps:
- prendre 3 thread dumps à 10s d'intervalle (kill -3 <pid> ou jstack -l <pid>)
- vérifier la présence de deadlocks
- comparer ensuite les 3 thread dumps avec un diff, meld ou autre et chercher les threads applicatif (type: http-nio-8080-exec-*) restés dans le même état sur les 3 thread dumps
- identifier la root cause du thread bloqué en regardant le code si nécessaire
lien origine: http://www.tomcatexpert.com/blog/2013/03/28/hanging-thread%E2%80%943-steps-troubleshooting-tomcat
Cloudbees a bossé sur des plugins Jenkins fournissant une chaine de construction d'images docker.
Exemple: repo git d'une appli java + une image OS = image docker avec OS + tomcat + war.
Ceci en prenant en compte le workflow nécessaire à l'intégration continue.
Pour en savoir plus, lire le livre blanc qui détaille leur travail: https://pages.cloudbees.com/rs/083-PKZ-512/images/Docker-Jenkins-Continuous-Delivery.pdf
"""
In case the number of tomcat threads and acceptCount values are set to be too high, a sudden increase in traffic will fill up the OS queues and make all the worker threads busy. When more requests than that can be handled by the system are sent to the machines, this "queuing" of requests is inevitable and will lead to increased busy threads, causing cpu starvation eventually. Hence, the crux of the solution is to avoid too much queuing of requests at multiple points (OS and tomcat threads) and fail fast (return http status 503) as soon the application's maximum capacity is reached. Here is a recommendation for doing this in practice:
Fail fast in case the system capacity for a machine is hit.
"""
Ca consiste juste à ajouter un élément context dans un élement host, dans le server.xml.
"""
<Host appBase="webapps"
autoDeploy="false" name="localhost" unpackWARs="true"
xmlNamespaceAware="false" xmlValidation="false">
...
<Context docBase="/home/stuff" path="/static" />
</Host>
"""
en fait y'a plus simple.
comme mettre un Xmx ridiculement petit genre moins de 10M et tenter de charger un war qui demande plus.
Dans le billet, l'auteur a mis le code d'une servlet qui provoque justement un 'java.lang.OutOfMemoryError: Java heap space'
Ceci afin de tester que le heap dump peut bien se créer à l'endroit qu'on a prévu.
parallel deployment
http://java-monitor.com/forum/showthread.php?t=1288
petit tuto simple pour logger dans syslog, grâce à log4j
déployer une nouvelle version d'un war sans indisponibilité :)
doc officielle: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Parallel_deployment
