Loadbalancing

Tomcat load balancing – mod_proxy vs mod_jk le m... http://blog.xebia.fr/2010/02/03/tomcat-load-balanci...
Blog Xebia France

J2EE, Agilité et SOA
Connexion
« Ma rencontre avec Ken Schwaber

Just DeployIt ! »
Une passion, la technologie.
Imaginez un environnement de travail qui valorise l'innovation

technologique et la curiosité.
Imaginez un groupe où vous aurez l'opportunité de travailler et partager

avec des gens parmi les plus talentueux.
Imaginez une culture et des valeurs en rupture avec les SSII.
Imaginez une société où vos talents et vos idées seront reconnus et

encouragés.
Imaginez une organisation qui vous donne les moyens réels de travailler, de
progresser, de réaliser vos projets personnels.
1 sur 43 09/06/2010 16:11

N'imaginez plus, vivez-le !
N'hésitez pas à nous contacter à travers le Formulaire de contact ou

directement à l'adresse recrutement@xebia.fr.
Thématiques
Android annotation BEA Cloud Computing développement Devoxx Eclipse ESB Exploitation Flash Flex
Google Grails Groovy GWT Hibernate IBM J2EE Java JavaFX jazoon JBoss jdk-7 JEE JPA JVM
Méthodes agiles Maven NoSQL Oracle OSGi Paris JUG Performance RIA scala SCRUM SOA
Spring SpringSource Sun Tomcat Websphere Wicket Xebia XP
Catégories
Divers (45)
Exploitation (24)
J2EE (81)
Java (169)
Méthodes agiles (66)
Mobilité (8)
Mot du président (15)
Performance (18)
Publications (4)
Quel beau métier ! (21)
Revue de presse (164)
RIA (26)
SOA (45)
Tests (1)
Xebia recrute ! (16)
2 sur 43 09/06/2010 16:11

Derniers billets
Revue de Presse Xebia
Jazoon’10 – Jour 2
Jazoon’10 – Jour 1
Xebia recherche un Responsable informatique / Administrateur Réseau
H/F (stage/apprentissage)
En route pour Jazoon’10
Rendez-vous exclusif : Mercredi 26 mai à 17h00 les Xebians en chat
pendant 2 heures !
KawaCamp jeudi 27 chez Xebia
Xebia recrute aussi des jeunes diplômés (H/F) !
Blogs anglophones
Eamonn McManus
Weblogic & Java EE
Blogs francophones
Bistro!
Le Touilleur Express
Xebia
Xebia Blog (NL)
Xebia Corporate
Xebia France
Xebia sur developpez.com
Archives
juin 2010
mai 2010
avril 2010
mars 2010
février 2010
janvier 2010
décembre 2009
novembre 2009
3 sur 43 09/06/2010 16:11

octobre 2009
septembre 2009
août 2009
juillet 2009
juin 2009
mai 2009
avril 2009
mars 2009
février 2009
janvier 2009
décembre 2008
novembre 2008
octobre 2008
septembre 2008
août 2008
juillet 2008
juin 2008
mai 2008
avril 2008
mars 2008
février 2008
janvier 2008
décembre 2007
novembre 2007
octobre 2007
septembre 2007
août 2007
juillet 2007
juin 2007
mai 2007
avril 2007
mars 2007
février 2007
décembre 2006
novembre 2006
A propos ...
Xebia est un groupe d'experts, exclusivement dédié aux technologies J2EE.
Licence
Sauf mention contraire, le contenu de ce blog est sous contrat Creative
Commons.
4 sur 43 09/06/2010 16:11

3 février 2010
Tomcat load balancing – mod_proxy vs mod_jk le

match
Dans notre article sur l'utilisation de HTTPS avec Tomcat en production, 22
nous avons étudié les solutions reposant sur la mise en place d'un reverse tweets
proxy HTTP. Nous n'avons pas oublié pour autant le protocole AJP. Ce retweet
protocole est né pour faciliter et accélérer les communications entre un serveur

web frontal et le serveur d'application JServ en back-end d'Apache. Avec le
temps, Tomcat a remplacé Apache JServ mais AJP est resté. Jusqu'en 2003, AJP
était la seule solution viable permettant de placer le serveur d'application
derrière un serveur Apache. Avec la maturation de la fonctionnalité Proxy dans
Apache est née la solution tout HTTP. Nous avons donc décidé d'organiser un
match opposant la solution AJP à la solution HTTP.
Un peu d'histoire
Tout commence en 1997 avec la création d'Apache JServ. A l'époque, il s'agit
d'un serveur de Servlet qui supporte uniquement le protocole AJP créé pour
l'occasion. Dans l'architecture initiale, c'est Apache 1.1 qui fournit le serveur
web et transfère les requêtes par socket au moteur de Servlet. C'est la naissance
du protocole AJP dans sa première version implémentée par le mod_jserv.
L'Apache JServ Protocol fonctionne au départ comme un proxy qui redirige le
flux vers JServ. Le protocole est en texte clair et utilise un caractère en début de
ligne pour distinguer les différents éléments de la requête.
Rapidement, le protocole initial est considéré comme trop limité car il fonctionne
uniquement en loopback et possède une authentification pauvre. En 1998, le
protocole AJP 1.1 permet à JServ de tourner sur une autre machine que le
serveur web et d'assurer une authentification forte basée sur md5. Avec le
développement de JServ appparaît un problème de performance important : le
coût d'ouverture d'une socket et la vitesse des réseaux. Ils sont considérés à
l'époque comme les principaux goulets d'étranglement. Pour résoudre ces
problèmes, le protocole passe à la version 1.2 dont vous trouverez le draft initial
ici. AJP 1.2 est un protocole binaire orienté paquets qui permet de recycler la ou
les sockets connectées à JServ. Le passage au binaire permet aussi d'améliorer
les performances car il diminue la taille des données qui transitent et simplifie le
traitement.
En 1999, Sun offre son implémentation de référence des Servlets à la fondation
5 sur 43 09/06/2010 16:11

Apache. C'est le point de départ des projets Tomcat et Ant. Commence alors une
période de transition qui finira par l'abandon d'Apache JServ. Pendant cette
transition, AJP sera porté sur Tomcat qui bénéficiera d'emblée d'une facilité
d'interconnexion avec Apache. Aux alentours de 2000, le mod_jk est développé
pour étendre AJP qui pourra supporter le transport des données SSL. C'est la
version 1.3 que l'on retrouve aujourd'hui supportée par les dernières
générations de Tomcat. Après toutes ces années de développement, le mod_jk est
maintenu par le projet Tomcat Connectors et n'a jamais été intégré aux projets
Apache.
La création d'AJP résulte donc de la simplicité et de la rapidité de

développement souhaitées par les auteurs. Il fallait aller vite, et implémenter un
proxy pleinement compatible HTTP aurait été trop long. Le module mod_proxy
existe depuis 1996 dans Apache 1.1. Mais il s'agissait d'une fonctionnalité
expérimentale qui n'offrait ni performance ni stabilité. A la sortie d'Apache 2, le
proxy a même été dé-scopé car il ne fonctionnait plus du tout. Les développeurs
vont pourtant rapidement le corriger et le réintégrer comme solution pour faire
des reverse proxies. Pour la sortie d'Apache 2.2, le mod_proxy est entièrement
réécrit pour supporter le load-balancing. Il offre, pour la première fois dans
Apache, une solution capable de concurrencer le mod_jk en performance et en
scalabilité. Cerise sur le gâteau, Apache a décidé de supporter nativement le
protocole AJP en ajoutant un mod_proxy_ajp à la solution mod_proxy.
Installation
mod_proxy
Le mod_proxy fait partie de la distribution standard d'Apache HTTPD. Il est livré

avec le mod_proxy_http, le mod_proxy_ajp et le mod_proxy_balancer. Il suffit
donc de s'assurer que ces modules sont bien chargés au démarrage d'Apache.
mod_jk
Si mod_jk était autrefois très délicat à installer avec la compilation du code sur
un serveur similaire au serveur cible, la situation s'est grandement simplifiée. Le
projet Apache Tomcat Connector fournit désormais les binaires pour les
principales plateformes (Linux, Windows, Free BSD, Mac, Solaris, AIX, etc). Il
faut donc télécharger le binaire du module et le copier dans le répertoire
contenant les modules Apache.
Configuration
Pour mieux comparer les deux solutions, nous avons choisi de prendre comme
exemple l'utilisation d'Apache en front desservant deux Tomcat en
6 sur 43 09/06/2010 16:11

load-balancing. Nous ne nous intéresserons ici qu'à la configuration d'Apache

HTTPD. La configuration AJP de Tomcat étant déjà largement documentée sur le
web et celle via HTTP dans nos articles précédents, nous n'aborderons pas ces
problématiques.
mod_proxy_http & mod_proxy_balancer
La configuration du mod_proxy consiste d'abord à s'assurer que les modules

soient bien chargés avec les directives LoadModule. Nous activons ensuite le server-
status ainsi que le balancer-manager pour obtenir une interface de surveillance /
administration du load-balancer. Enfin, nous avons configuré le Proxy balancer
nommé my-application-cluster pour contenir nos 2 serveurs Tomcat. La dernière
ligne de configuration active le reverse proxy pour que les requêtes sur
/my-application soient redirigées vers le /my-application du load-balancer.
Configuration avec mod_proxy_http & mod_proxy_balancer - httpd.conf
# LOAD MODULES
LoadModule proxy_module libexec/apache2/mod_proxy.so
LoadModule proxy_http_module libexec/apache2/mod_proxy_http.so
LoadModule proxy_balancer_module libexec/apache2/mod_proxy_balancer.so
# STATUS AND MONITORING

# Display proxy balancer status in /server-status page
ProxyStatus On
<Location /server-status>
SetHandler server-info
Order deny,allow
Deny from all
Allow from localhost
</Location>
<Location /balancer-manager>
SetHandler balancer-manager
Order Deny,Allow
Deny from all
</Location>
# APPLICATIONS CONFIGURATION
<Proxy balancer://my-application-cluster>
BalancerMember http://node-1:8080 route=node-1 disablereuse=On
# ...
BalancerMember http://node-n:8081 route=node-n disablereuse=On
</Proxy>
ProxyPreserveHost On
ProxyPass /my-application balancer://my-application-cluster/my-application stickys
Vous pouvez le constater, la configuration est parfaitement intégrée à la
7 sur 43 09/06/2010 16:11

configuration standard d'Apache HTTPD. Les équipes de production n'auront à

priori pas de grandes difficultés à prendre en main ce type de configuration qui
nécessite seulement de savoir parcourir la documentation Apache déjà bien
connue des administrateurs.
mod_jk
La première étape consiste à configurer le serveur Apache pour qu'il utilise le

mod_jk. Tout commence par le chargement du module avec la directive LoadModule.
Ensuite nous fournissons le chemin du deuxième fichier de configuration
définissant les workers. La directive JkMount permet ensuite d'associer un worker du
mod_jk à un pattern d'url du serveur. Pour chaque requête dont l'URL
correspond au pattern, Apache va déléguer le traitement au mod_jk. Nous
montons d'abord le worker jkstatus sur /jkmanager en autorisant l'accès uniquement
depuis le système local. C'est ensuite au tour du loadbalancer qui servira notre
application.
Configuration avec mod_jk - httpd.conf
# LOAD MODULES
LoadModule jk_module libexec/apache2/mod_jk.so
# MOD_JK CONFIGURATION FILE

JkWorkersFile /etc/apache2/other/workers.properties
# MOD_JK PROPRIETARY LOG FILE

JkLogFile /var/log/apache2/mod_jk.log
# NEEDED ON MAC SNOW LEOPARD

JkShmFile /var/log/apache2/
# STATUS AND MONITORING

JkMount /jkmanager/* jkstatus
<Location /jkmanager>
Order deny,allow
Deny from all
</Location>
# APPLICATIONS CONFIGURATION
JkMount /my-application/* loadbalancer
Il faut maintenant configurer le mod_jk proprement dit dans son fichier de

configuration spécifique. Il s'agit d'une liste de propriétés commençant toujours
par worker.. La propriété worker.list fournit les noms des workers actifs. Le nom est
ensuite utilisé pour paramétrer le worker avec des clés de la forme
worker.nomWorker.parametre. Le premier worker activé jkstatus utilise le type spécial
status qui correspond à l'interface de suivi et de gestion du mod_jk. Le deuxième
8 sur 43 09/06/2010 16:11

worker loadbalancer est en fait chargé de répartir les sessions entre le worker1 et le
worker2 via le type lb. Ce sont finalement les workers 1 à n qui assurent le
transport des requêtes sur AJP1.3 vers le port 8009 d'un Tomcat distant.
Configuration avec mod_jk - workers.properties
# WORKERS AND PSEUDO WORKER

worker.list=jkstatus, loadbalancer
# STATUS AND MANAGEMENT PSEUDO WORKER

worker.jkstatus.type=status
# WORKER 1 TO N
worker.worker1.type=ajp13
worker.worker1.host=node-1
worker.worker1.port=8009
# ...
worker.worker2.port=8009
worker.worker2.host=node-n
worker.worker2.type=ajp13
# LOAD BALANCER PSEUDO WORKER

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=worker1,worker2
Avec ses deux fichiers de configurations séparés et la syntaxe "rustique" du

worker.properties, la configuration est définitivement le point faible du mod_jk. L'un
des seuls avantages réside dans le nombre impressionnant de paramètres
supportés qui permet un paramétrage fin si le besoin s'en fait sentir. Si
seulement nous n'étions pas forcés à tant de verbosité !
Interfaces graphiques
Les deux modules fournissent des interfaces web pour assurer la supervision du
load-balancer. Cette fois, le mod_proxy se contente de fournir des statistiques
réduites dans une interface minimaliste. L'interface liste principalement le statut
de chaque nœud du load-balancer ainsi que la quantité de données envoyée et
reçue par nœud.
9 sur 43 09/06/2010 16:11

Outre le suivi des statistiques du load-balancer, le Balancer Manager permet

aussi de faire des modifications à chaud, éditer les workers, les passer en offline,
voire même changer la méthode de répartition utilisée.
De son côté, le mod_jk prouve sa maturité avec son interface rustique elle aussi,
mais plus voire trop complète. Elle est composée de plusieurs pages dont une
page d'accueil similaire en tout point à l'interface du mod_proxy. L'avantage
réside dans la fourniture d'une page détaillant l'état complet pour chaque nœud.
Mais le mod_jk ne se contente pas de cela : il fournit aussi une page permettant
de modiﬁer à chaud la conﬁguration du load-balancer. Il est parfaitement
envisageable pour le déploiement en production d'une nouvelle version de
l'application de couper les nœuds un à un au moment de leur mise à jour puis de
les réactiver sans interruption du service.
Attention toutefois, car les modifications faites par ce biais sont uniquement
enregistrées en mémoire, la nouvelle configuration sera perdue au prochain
redémarrage d'Apache.
10 sur 43 09/06/2010 16:11

La mince différence vient probablement de la jeunesse de la solution de

load-balancing du mod_proxy face à la longue expérience de production du
mod_jk. Mais elle ne saurait justifier une préférence pour l'un des deux modules,
qui sur ce point sont très proches.
LoadBalancing et gestion d'erreur

Outre la configuration et l'interface graphique, les deux solutions disposent de
quelques fonctions avancées notamment en ce qui concerne la gestion d'erreur
et la gestion des sockets réseaux. Les deux modules utilisent des pools de
connexion rangés par Thread du serveur Apache et par membres du cluster.
Avec le mod_proxy, il est possible de choisir parmi trois algorithmes de
répartition de charge :
Par requête : la charge est répartie pour chaque requête entrante en

fonction de la session si elle existe.
Par trafic réseau : les requêtes sont envoyées vers le membre du cluster
ayant reçu le moins de trafic.
Par taux d'occupation : la charge est répartie en fonction du nombre de
requêtes en cours de traitement ou en attente.
En ce qui concerne la gestion d'erreur, il n'y a pas grand chose à dire car il n'y a
pas grand chose de fait. Si un timeout claque, un certain nombre de tentatives
de reconnexion seront réalisées jusqu'à ce que le noeud soit marqué en erreur et
n'en décolle plus.
11 sur 43 09/06/2010 16:11

C'est sur la gestion d'erreur que le mod_jk possède une plus grande
sophistication que son récent concurrent.
Tout d'abord le protocole AJP fournit un mécanisme de health check
(CPing/CPong) qui permet de tester l'état du lien entre le serveur frontal et un
membre du cluster. Cependant, c'est beaucoup plus limité que les heart beat des
load balancer hardware, il n'est pas possible de tester une url pour détecter des
indisponibilités applicatives (échec de démarrage de la web app, web app KO à
cause de l'indisponibilité d'un backend clef).
D'autre part, le module fait une distinction entre les erreurs locales temporaires
qui sont sans impact particulier, un code d'erreur HTTP par exemple, et les
erreurs globales qui indiquent que le serveur est clairement en erreur et ne
recevra plus de nouvelles requêtes. Il existe un système d'escalade qui, en cas de
répétition trop fréquente d'erreurs locales sur un noeud se charge de le passer
en erreur globale. Le module se charge de réactiver le noeud en mode recovery
après un délai paramétré.
Côté répartition de charge, mod_jk apporte un dernier algorithme de répartition

reposant sur le nombre de sessions HTTP en cours par serveur. Cette méthode
est relativement récente puisqu'elle est apparue dans la version 1.2.20 du
mod_jk, actuellement en version 1.2.29. Elle est recommandée pour les
applications chargeant fortement la session et de ce fait, supportant un nombre
limité de sessions par serveur ; ce cas d'utilisation est assez marginal.
Dans les deux modules, l'algorithme de répartition est pondéré par un facteur
nommé "lbfactor", qui permet d'appliquer des quotas de travail aux serveurs. Ce
système s'avère utile si les serveurs sont de puissances différentes par exemple.
Le mod_jk marque ici un petit point sur le mod_proxy grâce à sa gestion d'erreur
plus fine. Attention aux effets de bord, le retry sur timeout en a surpris plus d'un
et l'éviction de serveurs tomcat pour cause de répétition d'erreur est un beau
sujet de déni de service
Pour le reste, le mod_proxy colle au fonctionnement du mod_jk, ce qui ne

manquera pas de faciliter son utilisation aux habitués du mod_jk.
Exploitation et diagnostic des problèmes

mod_proxy_http présente sur mod_jk le très grand avantage d'utiliser un
protocole standard, HTTP, connu de tous les acteurs d'un système d'information
alors que mod_jk repose sur le protocole AJP que quasiment personne ne
connait. Les administrateurs systèmes et réseaux sont habitués à HTTP et
notamment à ses connections persistantes (aka HTTP keepAlive) ; ils savent
ajuster leurs algorithmes de load balancing, les timeouts des firewalls et le
dimensionnement des piles tcp/ip des serveurs ( ulimit, tcp_keepalive_intvl,
tcp_tw_bucket, etc).
12 sur 43 09/06/2010 16:11

Un autre atout de mod_proxy est la facilité de diagnostic. N'importe quel acteur

du système d'information peut utiliser curl, wget, telnet, elinks voire wireshark pour
troubleshooter un problème de communication HTTP; ce n'est pas le cas avec le
protocole AJP qui n'est pas human readable et encore moins human writable.
Choisir AJP mérite de former les administrateurs systèmes et réseaux et de
prévoir des outils de tests permettant de requêter un connecteur AJP mais ce
n'est hélas que très rarement fait.
En cas de problème réseau avec HTTP comme avec AJP, n'oubliez pas que
désactiver les connections persistantes simplifie grandement les investigations et
n'a rien de scandaleux en 2010 (cf HAProxy) ; c'est " disablereuse=On" pour
mod_proxy_http et " JkOptions +DisableReuse" pour mod_jk
Conclusion
Avec sa simplicité de configuration, sa répartition de charge calquée sur le
mod_jk, le mod_proxy conviendra parfaitement dans la grande majorité des cas.
Il s'accommode de clusters répartissant la charge sur plusieurs noeuds ou bien
en tant que simple reverse proxy. La cerise sur le gateau étant l'utilisation du
protocole HTTP qui permet de garantir la portabilité des services et facilite
grandement l'analyse du trafic.
A nos yeux, avec l'intégration native de mod_proxy_http et

mod_proxy_balancer à Apache, il n'y a plus de justification à ajouter le
module additionnel mod_jk ni d'introduire le protocole méconnu AJP. Les
optimisations d'AJP ne sont plus de mise aujourd'hui et ne justifient
donc pas l'utilisation d'un mod_jk.
Il reste, dans les deux cas, quelques efforts à faire pour permettre de plus
facilement monter des serveurs à chaud dans un cluster. Pour la haute
disponibilité sans perte, il faudra mettre en place un cluster Tomcat assurant la
réplication des sessions utilisateur entre les serveurs. Encore faut-il en avoir
vraiment besoin ...
Attention, la recommandation de Tomcat est encore le mod_jk et, il est important

de garder fonctionnel ce qui marche déjà. Donc, quoiqu'il arrive, si vous avez
déjà une solution fonctionnelle avec le mod_jk, inutile de migrer. Pour ce qui est
de l'interface et de la gestion d'erreur, nous parions sur l'avenir du mod_proxy
qui est en développement intensif et bénéficie des corrections de bug de son
ainé. Reste un nouveau venu dans le paysage développé par Jboss qui attire déjà
notre attention c'est le mod_cluster actuellement, il n'est utilisable qu'avec Jboss
AS. L'avantage de cette nouvelle solution en devenir est de suivre le cycle de vie
des applications via un protocole spécifique MCMP reposant tout de même sur
HTTP.
13 sur 43 09/06/2010 16:11

Mots-clefs :Load Balancer, Reverse Proxy, Tomcat
Billets sur le même thème :
Tomcat : Adresse IP de l’internaute, load balancer, reverse proxy et header

Http X-Forwarded-For
Sécuriser Tomcat 5 derrière un proxy Apache 2 HTTPS
Tomcat, SSL, communications sécurisées et X-Forwarded-Proto
SpringOne 2009 – Sécurisation d’Apache Tomcat
Devoxx – Jour 1 – Applications robustes avec Amazon EC2
Auteur : Cyrille Le Clerc et Séven Le Mesle

Catégorie(s) : Exploitation, J2EE, Java
64 commentaires »
Vous pouvez suivre les réponses reçues par cet article grâce au fil des
commentaires.
64 réponses à “Tomcat load balancing – mod_proxy vs mod_jk le

match”
Le 3 février 2010 à 22:46 (), Henri Gomez a dit :
J'ai lu attentivement et avec intérêt cet article, qui montre une véritable
connaissance de ses problematiques de connectivité HTTPd / Tomcat.
Quelques commentaires quand même :
- ajp n'est pas un protocol si méconnu, il est présent dans jetty mais aussi
dans la liste des dissecteurs de l'analyseur de réseau Wire Shark.
- jk garde l'avantage pour les configurations clusters complexes. Vous avez

d'ailleurs bien présenté l'interface de configuration du routage, certes
rudimentaire mais bien pratique.
- mod_cluster pourrait être utilisé avec des Tomcat, JBoss As utilisant une
version de Tomcat proche du Tomcat standard.
- Longtemps l'objection contre mod_jk était qu'il devait être compilé, mais
les binaires Win32/64 et OS/X sont disponibles sur le site. Pour les Linux
c'est présent dans la plupart des distributions.
Pour finir l'avenir passera par un module qui saura détecter la topologie
dynamique des membres du cluster, leur capacité, leur charge afin
d'assurer un routage pertinent et automatique. mod_cluster est une bonne
piste de départ.
14 sur 43 09/06/2010 16:11

Le 4 février 2010 à 1:52 (), Cyrille Le Clerc a dit :
@Henri,
> ajp n'est pas un protocole si méconnu ...
La spécification d'AJP 1.3 est déconcertante, ça relève de l'archéologie

"Everything in this document is derived from the actual implementation I
found in the tomcat 3.x code. I hope it is useful, but I can't make any grand
claims to perfect accuracy" . On est bien loin de la rigueur des RFC du
protocole HTTP.
Mon expérience personnelle n'a pas été meilleure. Je n'ai peut être pas eu
de chance mais je n'ai jamais trouvé sur un projet des gens qui
connaissaient AJP ; par connaitre, j'entends plus que "savoir que ca existe".
A l'inverse, j'ai travaillé avec beaucoup de personnes très à l'aise avec
HTTP, des personnes qui n'avaient aucune difficulté à utiliser telnet ou un
tcpdump pour troubleshooter une communication défaillante.
J'ai l'impression que le niveau de maitrise d'AJP sur les mailing lists Tomcat
n'est pas tellement meilleur.
Pour l'outillage, je me sens très impuissant avec AJP, je ne connais aucun

client de requêtage équivalent aux telnet, curl et elinks que j'utilise
communément pour http. J'ai quand même une lueur d'espoir, un client
ajpget figure en 5ème point de la TODO list .
> clusters complexes, mod_jk et mod_cluster
Même s'il offre plein de paramètres très savants, mod_jk ne répond ni mieux
ni moins bien que mod_proxy_balancer à mes attentes de clustering.
J'aimerais avoir :
1) un graceful shutdown (aka session draining ) de chaque noeud pour ne
pas couper les sessions en cours,
2) un progressive startup pour laisser mon application s'initialiser en
douceur plutôt que d'avoir un démarrage en "burst" et des énormes à-coup
sur la répartition des sessions,
3) pouvoir scripter ces graceful shutdown et progressive startup ,
4) monitorer l'équilibrage de mes load-balancers avec Hyperic HQ.
Aujourd'hui, Zeus Load Balancer serait ma première piste mais il

complexifierait sensiblement mon architecture (ne se substitue pas à un
serveur Apache, demande un nouveau savoir faire, etc). Mod_cluster est sur
la bonne voie mais il me semble encore très jeune, sa documentation est
pour le moins spartiate
Cyrille (Xebia)
15 sur 43 09/06/2010 16:11

@Henri,
> avenir, détecter la topologie, ...
Je rêverai encore plus loin que vous : une Java Platform as a Service (1) !
Un deployment manager installerait mon war sur plusieurs noeuds de ma
grille avec exactement les versions de JVM et de serveur Java que je
demande.
JBoss App Server, JBoss ON & mod_cluster

Techniquement, JBoss a beaucoup de cartes en main avec mod_cluster et
JBoss App Server 5 dont l'administration est très intégrée à JBoss ON. Il n'y
a quasiment plus qu'à assembler les éléments entre eux.
Opérationnellement, JBoss a encore plus de cartes en main : ils sont déjà
dans tous les data centers avec RHEL, RHN Satellite et/ou JBoss App
Server.
Vont-ils remporter la mise pour autant ? Hélas, j'attends plein d'annonces

que ne viennent pas .
Quand l'agent JBoss ON pourra-il déployer les binaires d'une nouvelle

version de JBoss AS et d'une nouvelle JVM ?
Quand seront disponibles les docs sur le scripting de mod_cluster ?
Quand pourrais-je écrire un script de déploiement phasé d'une nouvelle
version de mon war ? Je voudrais "pour chaque noeud : graceful-shutdown-
mod_cluster + undeploy + deploy + test-d-url + progressive-startup" ,
Quand JBoss ON m'offrira des démarrages & arrêts automatiques de noeuds
sur mes clusters ? Je voudrais "si la charge CPU sur les noeuds du cluster >
60% alors démarrer l'application sur un noeud de réserve"
Prabhakar Gopalan, JBoss ON product manager, est conscient qu'il a de l'or

dans les mains mais je n'ai pas l'impression qu'il soit aidé par les stars de
JBoss. Stars qui travaillent toujours sur des frameworks et standards Java
certes très intéressants mais peut être moins stratégiques que de coiffer au
poteau SpringSource dans la course de Java Platform as a Service.
SpringSource tc Server, Hyperic et mod_proxy_balancer
SpringSource avec tcServer a aussi pour but de déployer facilement des

applications java clusterisées mais leurs fonctionnalités ont probablement
plus de 6 mois de retard sur JBoss.
Bien qu'Hyperic soit le produit original, ses fonctionnalités de déploiement

sont en retard sur celles de son fork JBoss ON / RHQ.
C'est pareil pour le load balancer : SpringSource mise sur
16 sur 43 09/06/2010 16:11

mod_proxy_balancer qui est lui aussi en retard mod_cluster que soutient

JBoss.
Et plus difficile encore, SpringSource est très discret dans les data centers ;
Hyperic HQ commence à peine à creuser sa place et tout reste à faire pour
tcServer.
Malgré cela, SpringSource est beaucoup plus présent que JBoss sur la
scène du Java Platform as a Service notamment avec le rachat de Cloud
Foundry qui leur permet de surfer sur la notoriété d'Amazon EC2.
En conclusion, mon rêve de "Java Platform as a Service" est très ambitieux

et je ne sais pas qui sera le vainqueur de la première manche
Cyrille (Xebia)
(1) cf Pourquoi VMWare / SpringSource ? Virtualisation matérielle vs. Cloud
Le 4 février 2010 à 7:30 (), Benoit Moussaud a dit :
Un deployment manager installerait mon war sur plusieurs noeuds de ma

grille avec exactement les versions de JVM et de serveur Java que je
demande.
Quand pourrais-je écrire un script de déploiement phasé d'une nouvelle

version de mon war ? Je voudrais "pour chaque noeud : graceful-shutdown-
mod_cluster + undeploy + deploy + test-d-url + progressive-startup"
Avec Deployit - Automated deployment for Java applications !, tu peux

facilement assembler toutes ces phases dans un plugin et d"ployer sur
l'ensemble des nœuds de ton environnement.
Benoit (Xebia)
Le 4 février 2010 à 8:16 (), Henri Gomez a dit :
Et si vous veniez discuter de tout ça sur Tomcat-dev ?
Il y a des commiters, dont votre serviteur, qui serait très content

d'échanger voir réfléchir à tous ces points.
Je vous accorde le point qu'AJP n'est pas le meilleur protocol en terme de

définition, norme et documentation.
C'est aussi pour ça que j'avais fait des propositions et add-on comme le
cping/cpong.
Si vous remontez dans les archives vous pourrez voir que le sujet de la
pondération du routage par collecte des infos de charge OS/webapp (voir
17 sur 43 09/06/2010 16:11

back end DB) a été évoqué plus d'une fois.
Mais vous avez déjà un des éléments de réponses à l'absence de certaines

fonctionnalités dans JK, SpringSource et JBoss ont des commiters dans les
projets Tomcat mais chacun avec des objectifs propres.
A très bientôt donc sur Tomcat-dev pour discuter de tout ça !
Le 4 février 2010 à 10:23 (), Benoît Dissert a dit :
Je ne comprend décidément pas la conclusion. Autant il est positif d'avoir

un protocole plain-text, compréhensif, répandu, autant il n'est pas
raisonnable d'espérer avoir avec le mod_proxy, le même niveau de
fonctionnalités qu'avec le protocole AJP.
En effet, les informations circulant entre Apache et Tomcat ne relèvent pas

toutes du niveau applicatif (HTTP). Entre autres :
- les informations concernant les erreurs et les ressources disponibles côté
tomcat, comme vous le dites très justement;
- si la connexion client-Apache est en HTTPS avec certificats clients, les
informations du certificats (comme je l'ai déjà dit dans un précédent
commentaire : http://blog.xebia.fr/2009/09/23/securiser-tomcat-5-derriere-
un-proxy-apache-2-https/#comment-15299).
Pour ajouter ces informations supplémentaires, comme le mod_proxy se base

sur le connecteur coyote (HTTP) classique de Tomcat, aucun information
non standard n'est connue. Si on veut utiliser les informations qui ne sont
pas de base en HTTP, il faut :
- tunneler ces informations dans le HTTP (via des headers HTTP "X-...") ;
- analyser ces informations côté Tomcat soit par un déploiement de Valves,
pour que ce soit transparent applicativement, soit justement faire une
interprétation applicative.
En conclusion, dès qu'on a des besoins un tant soit peu complexe, il faut
mettre en place des verrues pour utiliser le mod_proxy.
Personnellement, je n'ai pas rencontré un projet où l'on utilise le

mod_proxy, pour lequel il n'y a pas eu besoin de faire des développements
spécifique, uniquement à cause du mod_proxy.
A mon sens, le mod_proxy ne peut pas être une solution industrielle.
Benoît
@Benoit D,
18 sur 43 09/06/2010 16:11

Il ne me semble pas rédhibitoire d'utiliser des headers http

(X-Forwarded-For, X-Forwarded-Proto, etc) pour propager des informations
collectées en amont de mes serveurs Tomcat. C'est notamment utilisé par les
load balancers dédiés (e.g. Alteon, Big-IP, HAProxy, Zeus), les proxy cache
(e.g. Squid) ou les accélérateurs SSL mais aussi par des gros serveurs Java
EE comme Websphere ou Weblogic.
Je conviens que cela nécessite de nettoyer les headers http à l'entrée des
data centers mais je ne vois hélas pas d'alternative.
Pour les projets qui utilisent industriellement mod_proxy, l'adoption est

progressive et SpringSource, le plus gros contributeur Tomcat en ce
moment le préconise et MuleSource est sur la même longueur d'onde.
A titre personnel, j'ai en tête au moins un portail d'opérateur télécom
français qui l'utilise, ca se passe plutôt bien même si nous aimerions
beaucoup avec un progressive startup ... qui n'est pas plus disponible dans
mod_jk .
Pour les situations complexes dont vous parlez, j'ai l'impression qu'il y a le
plus souvent un load balancer hardware de niveau 7 suivi d'une couche de
serveurs web et seulement après nos serveurs Java.
Si le load balancer hardware intervient au niveau 7, c'est lui qui doit

transmettre les informations comme l'adresse ip de l'internaute, le protocole
utilisé (http/https), le certificat ssl client utilisé, etc ; dans ces situations qui
utilisent une communication http, je pense aux headers X-Forwarded-For,
X-Forwarded-Proto ou X-Client-Cert.
Les deux premiers sont déjà traités dans Tomcat avec RemoteIpValve, il ne
nous reste qu'à apporter l'intégration des certificats SSL clients .
Pour revenir à AJP et mod_jk, si mon serveur Apache Httpd est précédé d'un
load-balancer ou un firewall de niveau 7, je ne vois pas comment il est
possible de récupérer l'adresse IP de l'internaute sauf à utiliser
mod_remoteip qui n'est disponible que sur Apache 2.3.5-alpha ; pour ssl,
ai-je d'autre solution que des headers http ?
En revanche, si je peux me dispenser de composants réseau de niveau 7 en
amont des Apache, je conviens que mod_jk permet plus facilement que
mod_proxy_http
de récupérer ces informations. Hélas, ca n'a pas été le cas sur mes projets
ces dernières années.
Cyrille (Xebia)
Le 4 février 2010 à 12:11 (), Olivier Jaquemet a dit :
Je plussoie sur les remarques de Benoit.
19 sur 43 09/06/2010 16:11

D'après ma (petite) expérience, le choix de modproxy est toujours effectué

par des architectes sous des prétextes de sécurité (DMZ ou protocole HTTP
only) au détriment des problématiques de performance (eg : service des
fichiers statiques par apache) et des fonctionnalités applicatives (eg :
récupération des IPs clients).
Je pense effectivement que modproxy peut se justifier pour certaine

applications dédiées (crée pour cette architecture) ou le besoin
fonctionnelle est limité. Mais je reste persuadé que modjk est plus riche et
plus adapté pour les applications complexes.
Le 4 février 2010 à 12:13 (), Benoît Dissert a dit :
@Cyrille Le Clerc
Je n'ai rien contre l'usage des "X-Forwarded-For", "X-Forwarded-Proto", qui

sont des headers "standards" (de fait en tout cas) des reverses proxies.
Ce que je n'aime pas, c'est d'ajouter des informations non standard

adhérentes spécifiquement à l'architecture HTTPD/mod_proxy/Tomcat. Et
du coup, mettre du code spécifique en plus de part et d'autre.
(Il y a eu une erreur de DB lors de mon premier submit, désolé si le

commentaire apparait en double)
@Olivier
Pour la performance, les différents benchmarks AJP vs. HTTP disponibles

sur internet montrent qu'il n'y a pas grande différence. Si HTTP avait des
problèmes de performances, j'imagine que Weblogic et Websphere auraient
conservé leur protocoles propriétaires plutôt que de l'adopter.
Pour le service des ressources statiques, je préfère parler de ressources

cachables et recourir à un proxy cache (Squid, mod_cache, etc) avec des
headers Expires et Cache-Control bien positionnés. Je travaille actuellement sur
un gros portail qui utilise mod_disk_cache avec satisfaction (en complément d'un
CDN). Cette approche est indépendante de AJP vs. HTTP pour connecter
Apache à Tomcat.
Pour les problématiques de récupération des IP clientes, si le serveur

Apache est précédé d'un load-balancer ou un firewall de niveau 7, AJP aura
autant besoin de X-Forwarded-For que HTTP.
Cyrille
20 sur 43 09/06/2010 16:11

@Benoit D,
Je vous rejoins sur le problème du standard de ces headers liés à SSL :
* F5 BIG-IP émet SSLClientCertStatus, SSLClientCertSN et

SSLClientCertb64
* Weblogic consomme WL-Proxy-Client-Cert et WL-Proxy-SSL
* Websphere utilise un header configurable httpsIndicatorHeader et
d'autres headers spécifiques que je n'ai pas eu le temps de trouver dans les
docs.
* Microsoft Internet Security & Acceleration (ISA) émet Front-End-Https
* X-Client-Cert
* ...
Tout le monde propose une solution à base de header http, c'est

incontournable lorsque SSL est déplié par un load balancer dédié ou des
accélérateurs SSL.
Après, Squid a réussi à imposer le standard de-facto "X-Forwarded-For",

nous pouvons suivre le conseil d'Henri rejoindre la mailing list Tomcat pour
intégrer l'envoi de certificat client par header http et promouvoir un nom
de header .
Cyrille
Le 4 février 2010 à 14:53 (), Olivier Jaquemet a dit :
Merci Cyrille pour ces précisions.
Effectivement il existes d'autre alternative pour résoudre les

problématiques de performances. Mais comme c'est justement là que mod_jk
tire toute sa richesse; bien configuré il se suffit à lui même !
Pas besoin de configurer d'autre module pour obtenir de bonne
performance, pas besoin de faire de développement spécifique pour
récupérer les IPs, idem pour le SSL...
Juste par curiosité, sauriez-vous me donner un pourcentage de projets dans

lesquelles vous avez mis en oeuvre des loadbalancer de niveau 7 ? Quel était
le besoin ?
@Olivier,
Pour l'amélioration des performances en optimisant les flux, le projet
21 sur 43 09/06/2010 16:11

Chromium - SPDY: An experimental protocol for a faster web mené par

Google changera peut être les lignes de front.
Pour les environnements dans lesquels j'ai ou des collègues ont utilisé des
load balancers de niveau 7 en amont des serveurs web, j'ai en tête :
* les portails grand public et gateway web services de deux des trois grand
opérateurs telco français,
* deux grandes banques françaises en intranet et site web grand public
(HAProxy n'est pas très éloigné de l'une d'elle ),
* une compagnie d'assurance,
* Une radio nationale,
* ...
> Quel était le besoin ?
La haute disponibilité d'un load balancer hardware en single point of

failure, l'accélération SSL, le firewalling http (URL malicieuses, DOS, audit,
etc) et la culture des équipes réseaux qui aiment beaucoup les load
balancers hardware.
Quelle solution de load balancing hautement disponible placée en single

point of failure avez vous en tête ?
Les approches non-hardware comme HAProxy sur un simple Linux me

semblent très intéressantes mais je n'ai jusqu'à présent jamais trouvé
d'équipe réseaux réceptives, l'image de fiabilité d'un appliance rassure
énormément.
Cyrille
Le 4 février 2010 à 17:39 (), Marco a dit :
Bonjour,
merci pour ce post et dont je partage les conclusions(nous avons jk 1.2.27
en prod)
juste une question cependant
as tu a un lien sur le session draining ?
Quelle difference avec le status disabled de noeuds en jk
Cordialement
Marc Godin
Le 4 février 2010 à 21:09 (), Séven Le Mesle a dit :
Bonsoir,
en ce qui concerne les performances je n'ai pas constaté de problèmes

majeur sur mon projet actuel lié à mod_proxy. Il est vrai que l'optimisation
22 sur 43 09/06/2010 16:11

si besoin passe par l'utilisation de différents modules apache comme

mod_expires, mod_disk_cache et le mod_deflate, mais c'est a priori le
standard Apache.
A priori, sortie de sa boite, ni Apache, ni Tomcat ne sont très optimisés. De
plus, je me permet de rappeler que le moteur SSL d'Apache est bien plus
performant que son homologue Java. Côté Tomcat pour la performance il
faudra utiliser l'extension native: http://tomcat.apache.org/native-doc/.
Reste le problème des certificats en proxy SSL, et il existe une solution que
nous avons volontairement ignoré jusqu'à maintenant. Il s'agit du
mod_proxy_connect qui fournit la directive AllowConnect. Cette directive
permet de forwarder purement et simplement le traffic SSL vers l'un des
serveurs du load balancer. C'est justement la tendance habituelle à
l'utilisation de headers HTTP pour communiquer les informations du clients
initiale qui nous ont fait ignorer. Car finalement en observant ce qui se fait
aujourd'hui en matière de proxy, nous avons pu constater que la norme est
précisément d'utiliser des headers. Je reconnais bien volontier qu'il y a un
flou artistique autour de cette question, mais il y a bel et bien des solutions,
y compris sans développement spécifique.
@Marco,
Voici les liens que je connais sur le session draining / graceful shutdown :
Zeus : Zeus 6.0 User Manual - 11.2.5 Draining Connections et How can I
remove back-ends from the cluster without disrupting sessions?.
mod_cluster : hélas, je n'ai rien trouvé dans la documentation si ce n'est

cette mention sur un blog : mod_cluster 1.1.0 Beta1 released par Paul
Ferraro (JBoss). La documentation est spartiate mais la fonction est
disponible !
Pour le status : disabled , j'ai fait il y a quelques mois des essais avec
mod_proxy_balancer qui hélas s'étaient soldés par un échec puisque plus
aucune requête http n'est transmise à un noeud disabled ; passer le loadfactor à
0 n'a pas marché non plus car l'interface graphique interdit cette valeur.
J'avais trouvé pour astuce de passer le loadfactor du noeud que je voulais
éteindre à 1 et celui de tous les autres noeuds à 100 ; quasiment plus aucune
nouvelle session n'était envoyée vers le noeud à éteindre mais ce n'est que
de la bidouille .
En revanche, je n'ai pas testé le fonctionnement de mod_jk lorsqu'on disable

un noeud / worker.
Cyrille
23 sur 43 09/06/2010 16:11

@Henri,
Merci pour l'invitation à exposer nos idées sur la mailing list Tomcat et pour
y avoir cité ce billet.
J'y ai apporté ma modeste mais néanmoins chronophage contribution avec

RemoteIpValve qui vient d'être disponible avec Tomcat 6.0.24 et pour
lequel j'aimerais améliorer la documentation.
J'ai aussi récemment ouvert une discussion avec "JMX Client
UnmarshalException with JmxRemoteLifecycleListener and
useLocalPorts="true"" qui va vraisemblablement m'amener à me plonger
dans l'utilisation de RMI par le JMXConnectorServer. Mais la perspective
d'utiliser VisualVM au travers d'un tunnel SSH m'émoustille tellement .
Ensuite, contribuer à la gestion dans Tomcat d'un header http portant le

certificat X509 client pourrait être excitant, Séven semblait sur la même
longueur d'onde cet après midi .
Cyrille
Le 5 février 2010 à 9:33 (), Marco a dit :
Merci pour ta réponse,

pour le status disabled du modjk, pour le moment je dirait être a peu près
sur du fonctionement(on ne se sert pas beaucoups de la possibilité de
mettre en prod à chaud)
Par contre j'avais juste une remarque sur le modjk et la gestion d'erreur,
même si elle paraît assez complete elle gére seulement les codes retours
http, planté sur un 404 ca oblige à verifié que personne n'a oublié un seule
ressource même pas un css dans les webapps...
bilan,
il manque un la possibilité de tester un get de son choix
ce qu'offre par ex les LoadBalancer standards genre bigIP
Cordialement
Marc
Le 7 février 2010 à 10:39 (), Mike a dit :
Bonjour.
J'ai du rater quelque chose, mais pourquoi ne pas utiliser mod_proxy_ajp
qui apporte finalement le meilleur de mod_proxy et de mod_ajp ? Tu en
parles brièvement au début de l'article comme la "cerise sur le gateau", et
puis ça disparait ...)
Personnellement, je n'utilise plus que mod_proxy_ajp depuis qu'il est
24 sur 43 09/06/2010 16:11

intégré à apache 2.2 (cad, de puis longtemps. Je ne pensais pas que mod_jk
était toujours utilisé ... ).
Ce que je reprochais particuliérement à mod_jk, c'est

- le fichier workers.properties unique qui ne permet pas de séparer les
configurations des projets dans le cas d'un hébergement mutualisé.
- le fichier de log, là aussi commun à tous les projets.
@Marco,
Merci pour ce retour d'expérience.

La gestion d'erreurs de mod_jk me semble d'autant plus complexe à
comprendre que certaines fonctionnalités à l'apparence "sexy" peuvent
jouer de très mauvais tour.
* Le mécanisme de retry qui réémet la requête vers un autre noeud du

cluster en cas d'erreur de communication vers un premier noeud est trop
optimiste et activé par défaut ( retries: 2).
Le fait qu'un timeout de réponse ( reply_timeout) soit éligible à un ré-essai,
même sur des POST, m'a déjà causé des doubles appels inattendus .
* La désactivation de noeud de cluster sur exception peut causer des arrêts
inattendus et être une faille importante de déni de service.
** Les mécanismes de Reply Timeout sont très délicats à gérer en cas de
requêtes longues.
** L'invalidation d'un noeud sur code d'erreur (fail_on_status) est séduisant
mais difficile dans la réalité car si Tomcat retourne une 503 lorsqu'il
redémarre, c'est en revanche une 404 lorsque le démarrage d'une web
application a échoué. Qui oserait configurer 404 ou 500 comme causes
d'arrêt d'un noeud de cluster ?
Dans les faits, mon plus grand problème est qu'une webapp ne démarre pas
pour un défaut de configuration et j'aimerais alors que Tomcat, plutôt que
de retourner une erreur 404, s'arrête.
Même les erreurs 503 ne me satisfont plus depuis l'émergence de REST :

503 est un code intéressant pour exprimer qu'un service est indisponible
parce qu'un backend est en maintenance. Cependant, un service
indisponible ne signifie pas que la web app entière est indisponible.
Pour la page de healthcheck invoquée par des load balancer à la

BigIP/Alteon, même si on peut en théorie faire des tests très sophistiqués, je
me suis jusqu'à présent limité à des pages quasiment vides : je n'ai jamais
pris le temps d'écrire des pages qui faisaient des vrais tests sans pour
autant trop nuire aux performances.
25 sur 43 09/06/2010 16:11

Cyrille (Xebia)
@ Mike,
Merci pour ton complément.
Je te rejoins sur l'intérêt à l'unification des fichiers de configuration et de

log qu'apporte mod_proxy par rapport à mod_jk. Nous avions oublié de
parler des logs de mod_jk mais je me souviens avoir déjà complètement
oublié que mod_jk avait son fichier spécifique et m'être focalisé sur un
error_log désespérément vide alors que mod_jk.log pesait plusieurs Go ! Très
vexant .
Cependant, le point le plus décisif pour moi dans mod_proxy_balancer +

mod_proxy_http est d'utiliser HTTP plutôt que AJP. Les gens connaissent,
savent tester et savent tuner HTTP beaucoup plus que AJP.
Je prendrais presque ton contrepied en suggérant mod_proxy_http +

mod_cluster pour bénéficier du session draining et de l'API de scripting de
mod_cluster tout en utilisant HTTP ... quand la documentation de
mod_cluster sera plus fournie .
Cyrille (Xebia)
Le 8 février 2010 à 15:27 (), Séven Le Mesle a dit :
Tout d'abord, un grand merci à Cyrille pour avoir assuré un service

après-vente exceptionnel sur notre article.
Je me permet de te répondre aussi Mike pour la question du mod_proxy_ajp,
si nous parlons du support AJP dans le début de l'article c'est surtout pour
indiquer aux inconditionnels du genre qu'ils peuvent migrer en minimisant
les risques vers cette solution, et qu'elle est à peu de chose près
iso-fonctionnelle.
Mais comme tu l'auras compris, nous sommes Cyrille et moi convaincus que
c'est par HTTP que le salut vient. C'est d'ailleurs le point de vue que nous
avons tenté de mettre en avant dans l'historique d'AJP qui montre les
faiblesses du protocole devenu standard de facto. A mon sens, le succès
d'AJP vient surtout de son histoire et de toutes ces années ou il fût la seule
solution possible. Mais maintenant qu'il existe une solution full HTTP pour
faire tourner un serveur HTTP, je suis totalement partisan de cette
dernière.
Cette solution à été particulièrement appréciée par les auditeurs de
sécurité d'une grande régie de transport parisien qui préfère largement
l'homogénéité des flux réseaux. C'est très utile en résolution de problèmes
26 sur 43 09/06/2010 16:11

mais c'est aussi utile pour maintenir une topologie réseau simple.
Du reste, à mon tour je te rejoins totalement sur l'efficacité de la

configuration Apache native qui permet de tuner facilement les
configurations de proxy et de logs séparés par hôte virtuelle par exemple.
Donc une fois encore les avantages principaux sont d'utiliser HTTP d'abord,
puis l'intégration native à Apache qui offre une facilité de configuration
largement accrue.
> Le salut vient d'HTTP
Je serais un zeste plus modéré et diplomatique .
Je trouve qu'AJP13 et mod_jk sont aujourd'hui respectivement moins

intéressants aujourd'hui que HTTP et mod_proxy_balancer.
Cependant, selon l'adage il ne faut pas dire "Fontaine je ne boirai pas de ton
eau" , je n'exclue pas qu'un jour, HTTP soit dépassé par des protocoles
comme SPDY et que mod_proxy_balancer devienne moins intéressant que
des initiatives extérieures à Httpd comme mod_cluster .
Hier, AJP&mod_jk, aujourd'hui HTTP&mod_proxy_balancer, demain ???
Cyrille
Le 8 février 2010 à 16:47 (), fabrice a dit :
Du même avi que Mike, On peut utiliser conjointement mod_proxy et ajp
exemple de configuration :
BalancerMember ajp://node1:8060 route=tomcat1 ping=2
BalancerMember ajp://node2:8060 route=tomcat2 ping=2
ProxyPass / balancer://pool/ stickysession=JSESSIONID

ProxyPassReverse / balancer://pool/
avantage : on a un début de healthcheck sur le tomcat (avec l'option ping)

+ le tomcat reçoit tous les headers du client sans "bidouilles"
Pour moi le gros problème avec proxy_http, c'est que l'on a aucun
healthcheck, or un load balancing sans healthcheck, ca ne marche qu'en
fonctionnement nominal, quand tout est up and runing .....
En http, si un des tomcat est parti en vrille, le balancer continuera à lui
27 sur 43 09/06/2010 16:11

envoyer des requêtes sans broncher .... pas cool
C'est pour cela que sur les loadbalancer hardware type F5-BigIP, on peut
(et on doit) configurer une URL de healthcheck
--Fabrice
Le 8 février 2010 à 23:34 (), marc godin a dit :
@Cyrille:
Dans les faits, mon plus grand problème est qu'une webapp ne démarre pas
pour un défaut de configuration et j'aimerais alors que Tomcat, plutôt que
de retourner une erreur 404, s'arrête.
->j'en parlé sur le forum tomcat mais il ne demordent pas que si la page est
absente un 404 est la bonne réponse http, on peut les comprendre, on
regrette juste que ce code de retour soit dans le marbe...*
@Cyrille
* La désactivation de noeud de cluster sur exception peut causer des arrêts
inattendus et être une faille importante de déni de service.
** Les mécanismes de Reply Timeout sont très délicats à gérer en cas de
requêtes longues.
c gentils de prevenir mais pour moi c trops tards ca ma déja planté mes 6
serveurs
@Fabrice,
Je serais comme vous intéressé par un mécanisme qui permettrait

d'invalider un noeud devenu indisponible ; les mécanismes de healthcheck
sont très adaptés à ce besoin.
Cependant, je viens de refaire les tests : AJP (via mod_proxy_ajp et mod_jk) ne

détecte pas plus que mod_proxy_http l'indisponibilité d'un noeud pour un
problème aussi flagrant que l'échec de démarrage d'une web application. Il
en sera de même pour tout indisponibilité qui ne saturera pas le
connecteur. Par exemple, un " too many open files" retournera une 500
immédiate qui ne sera pas vue par le ping AJP.
Par conséquent, je vous rejoins sur l'intérêt d'un healthcheck pour tester la
disponibilité d'un noeud de cluster mais seulement si c'est un healthcheck
applicatif ; cela passerait probablement par le requêtage d'une URL.
Le ping AJP est en ce sens un faux ami à mes yeux. Il permet de détecter les
échecs de communication vers le connecteur que mod_jk et mod_proxy_balancer
détectent aussi en échouant l'acheminement d'une requête. Le seul gain est
que le ping AJP détectera peut être l'indisponibilité avec une tentative
28 sur 43 09/06/2010 16:11

d'acheminement. En revanche, si mon trafic est important, la plus grande

probabilité est qu'une requête échoue avant le passage du ping.
@Marc,
Merci d'avoir défendu la cause de la 503 plutôt que la 404 en cas d'échec
de démarrage d'une web application !
J'avais une idée similaire : forcer l'arrêt d'un Tomcat si une application
échoue à démarrer. Un simple ContainerListener Tomcat devrait suffire. Dès
que je trouve le temps ...
Cyrille
Le 23 février 2010 à 0:21 (), Marc godin a dit :
je reviens sur cet pseudo affirmation de ma part:

pour le status disabled du modjk, pour le moment je dirait être a peu près
sur du fonctionement
et je remplace fonctionement par disfonctionement

après le post de cyrille j'ai refait des tests en coupant des pattes à mon
cluster
et la surprise a été très mauvaise de voir que des requêtes arrive encore sur
mes noeud disabled
cela m'étonne et je vais m'enpresser de lancer un post pour les devs du
modjk
j'ai surement du raté un truc ce peut pas être possible.....
cdlt marco
Le 22 avril 2010 à 16:53 (), Jean a dit :
Bonjour,
J'essaie de rediriger "http://localhost:8080/monsite/index.do" vers

"http://test-monsite.com".
Je ne veux pas avoir 8080 et /monsite dans l'url. Pour cela j'utilise
apache2.2 coupler avec tomcat6 (en utlisant proxy_ajp_module).
J'ai crée un vhost dans apache:
ServerName test-monsite.com
ServerAlias test-monsite.com
ErrorLog "logs/monsite.com-error.log"
CustomLog "logs/monsite.com-access.log" common
ProxyPass / ajp://127.0.0.1:8009/monsite/
ProxypassReverse / ajp://127.0.0.1:8009/monsite/
29 sur 43 09/06/2010 16:11

Mon problème est quand je demande http://test-monsite.com il

me redirige vers http://test-monsite.com/monsite/index.do.
Pouvez vous me donner quelques indications stp.
Merci d'avance
Le 22 avril 2010 à 17:28 (), Mike a dit :
En théorie, c'est ce à quoi sert la directive

ProxyPreserveHost On
...
Oups ... pardon ... je suis allé trop vite

Je ne pense pas qu'il y ait de solution.
Eventuellement, avec une RewriteRule comme
RewriteRule ^/$ /monsite/index.do
mais ca risque de poser des problèmes ensuite pour l'accès aux ressources
statiques ...
Il faudra de plus peut-être transformer les ProxyPass en RewriteRule aussi

car ProxyPass risque d'être propriétaire.
Essayez donc avec
RewriteEngine On
RewriteRule (.*) asp://127.0.0.1:8009$1 [P]
et en supprimant les ProxyPass ...
Bonjour,
Merci pour votre réponse.

J'ai essayé cela en modifiant modifiant mon vhost comme ceci:
ServerName test-monsite.com
ServerAlias test-monsite.com
ErrorLog "logs/monsite.com-error.log"
CustomLog "logs/monsite.com-access.log" common
RewriteEngine On
RewriteRule (.*) ajp://127.0.0.1:8009$1 [P]
30 sur 43 09/06/2010 16:11

Il marche maintenant pour la page d'accueil de mon site enfin presque.

Cependant lorsque je navigue dans les autres pages du site il rajoute tjrs
"/monsite. Exemple : http://test-monsite.com/monsite/mapage.jsp au lieu de
http://test-monsite.com/mapage.jsp
En attendant de vous lire je vous remercie par avance.
Cdt
Oui, mais là, on ne peut plus rien faire.

Si c'est à un moment passé sur "/monsite" c'est que c'est le serveur qui a
renvoyé ce lien.
La seule option est donc de mettre la webapp en contexte root ...
je dois avoir plusieurs sites déployés sur la même instance de tomcat.

Donc j'aurai besoin de plusieurs vhosts.
Si je mets la webapp en contexte root(d'ailleurs comment?)
ça ne va pas me poser des problèmes?
Merci
Cdt
Le 24 avril 2010 à 15:49 (), toty a dit :
Bonjour,
Une question de débutant.

Quel est la configuration pour avoir des un serveur apache en front qui va
intérroger plusieurs tomcat en backend en utilisant le mod-proxy_ajp ?
Ou bien le mod_proxy_balancer est à utiliser pour faire du loadbalancing

avec proxy_ajp ?
Merci de votre lumière.

Toty
Le 25 avril 2010 à 22:36 (), Cyrille Le Clerc a dit :
@Jean,
J'ai l'impression d'arriver après la bataille, j'espère que vous serez

indulgent.
31 sur 43 09/06/2010 16:11

En général, je préfère n'avoir qu'une seule web application par instance

Tomcat et avoir plusieurs instances Tomcat par serveur physique.
L'empreinte mémoire de Tomcat est tellement petite que cela ne pose en
général pas de problème.
Si vous ne pouvez séparer vos applications sur des instances Tomcat

dédiées, la piste des host dédiés me semble alors la plus élégante.
Ensuite, le problème de changement d'URI ("/" -> "/monsite") me semble

introduire une complexité source de bugs récurrents (toutes les urls
doivent être relatives, etc) et je préfère avoir avoir les mêmes URI sur les
serveur Tomcat et Apache. S'il s'agit du contexte racine ("/"), on peut le
faire en :
- nommant le war ROOT.war pour les déploiements par war,
- définissant l'attribut path à "" dans la configuration <Context path="" ... > pour
les déploiements par configuration (modification de server.xml ou ajout d'un
fragment .xml dans $CATALINA_BASE/conf/Catalina/localhost *).
* Catalina et localhost correspondent respectivement au name de l'Engine et du

Host.
Cyrille (Xebia)
@ toty
mod_proxy_ajp ne traite que du protocole AJP, au même titre que

mod_proxy_http qui gère HTTP. Si vous voulez que votre serveur Apache
redirige les requêtes vers plusieurs serveurs Tomcat, il faut en plus
configurer mod_proxy_balancer.
Vous aurez une configuration qui ressemblera à :
<Proxy balancer://my-application-cluster>
BalancerMember ajp://node-1:8009 route=node-1 disablereuse=On
# ...
BalancerMember ajp://node-n:8009 route=node-n disablereuse=On
</Proxy>
ProxyPass /my-application balancer://my-application-cluster/my-application sti
Cyrille (Xebia)
Bonjour,
32 sur 43 09/06/2010 16:11

Merci pour votre réponse!

J'ai respecté vos conseils et concernant mon 1èr vhost tout marche
maintenant
( j'ai mis la web app en context root).
Par contre pour l'autre vhost j'ai le problème suivant:
Quand je demande http://test-monsite.com/mapage.jsp, j'obtiens ce lien à la
place http://test-monsite.com/monsite/mapage.jsp. Donc un "/monsite" de
trop dans l'url.
Et il m'est impossible de mettre la webapp de cette application en context
root car il y'en a déjà un (la 1ère application) dans mon tomcat.
Cdt
@Jean,
Ne pouvez-vous pas créer un vhost Tomcat pour cette application destinée à

un contexte root ?
Si mes comptes sont justes, vous auriez alors 3 vhosts.
Cyrille (Xebia)
En résumé j'ai 2 vhosts:

1) dont l'application destinée au contexte root
Celui-ci marche
2)qui pose problème car le context est rajouté dans l'url.
Donc comment faire pour ne pas avoir le context dans l'url?

L'application utilise le Framework Struts.
Voici le vhot du 2èm appli:
ServerName test-appli2.com
ServerAlias test-appli2.com
ErrorLog "logs/test-appli2.com-error.log"
CustomLog "logs/test-appli2.com-access.log" common
RewriteEngine On
RewriteRule ^/$ /appli2/index.do
RewriteRule (.*) ajp://127.0.0.1:8009$1 [P]
Merci pour votre aide.
33 sur 43 09/06/2010 16:11

@Jean,
Ne pouvez-vous pas déclarer un Host Tomcat dédié au nom de host "test-

appli2.com" et y déclarer votre deuxième application comme contexte root ?
La configuration Tomcat ressemblerait à :
<Host name="localhost" appBase="webapps" ...>

...
</Host>
<Host name="test-monsite.com" appBase="webapps-test-monsite.com" ...>

<Context path="" docBase="${path-to-appli-1}" .../>
</Host>
<Host name="test-appli2.com" appBase="webapps-test-appli2.com" ...>

<Context path="" docBase="${path-to-appli-2}" .../>
</Host>
Cyrille (Xebia)
Je viens de finir les tests.

Tout marche très bien.
Thx you very much
Je vous en prie
Cyrille
Le 12 mai 2010 à 10:43 (), Jean a dit :
Bonjour,
J'ai développé une application multilangue en struts et mes urls sont sur
cette forme http://monsite/mapage.do?locale=fr.
Comment les transformer (avec apache je pense que c'est la meilleur
solution ???) pour qu'il soit visible pour l'utilisateur comme suit
http://monsite/fr/mapage.do.
Transformation à la volée de tous le urls en remplaçcant ?locale=fr par /fr/
Merci
Votre aide sera vraiment utile
Le 12 mai 2010 à 17:00 (), Séven Le Mesle a dit :
34 sur 43 09/06/2010 16:11

@Jean,
pour réaliser ce type de transformation d'URL, il faudra vous tourner vers le

mod_rewrite d'apache.
Cela vous permettra de modifier les URLs exposées aux utilisateurs tout en
recevant le paramètre locale=fr.
Par contre je vous recommanderai peut-être plutôt une URL du type
/mapage/fr à rediriger en /mapage.do?locale=fr.
Mais c'est à vous de vous faire votre propre avis sur ce point.
Le 12 mai 2010 à 19:23 (), Jean a dit :
Oui effectivement j'ai essayé mod_rewrite d'apache mais en vain

(RewriteRule).
Vous n'aurez pas un exemple à me montrer.
Merci
Le 17 mai 2010 à 9:17 (), Cyrille Le Clerc a dit :
@Jean,
J'aurais une approche assez différente de mod_rewrite.
Votre besoin de reconstruction du fichier ".jsp" est spécifique à votre web

application et non un comportement général à l'ensemble de votre site, à
l'ensemble des pages webs servies par votre serveur Apache. J'imagine que
le prefixage par la locale (e.g. "fr") ne s'applique pas aux servlets). Votre
besoin me semble relever de la technique d'implémentation de
l'internationalisation de votre framework de présentation.
Apache Httpd vs. web application
J'invoquerai deux principes pour implémenter ce comportement dans la web

application plutôt que dans le serveur web amont :
* La cohésion : eviter de disperser le comportement d'une application sur
d'autres composants que l'application elle même.
* Le découplage : eviter d'ajouter des comportements spécifiques d'une
application à des composants mutualisés comme un serveur web.
Url Rewrite Filter & regexp vs Servlet Filter dédié
Techniquement, votre besoin semble réalisable avec les expressions

régulières de l'Url Rewrite Filter (port en java de mod_rewrite). Cependant,
je suis assez réticent aux solutions par expressions régulières génériques
que je maitrise mal et que je trouve peu explicites alors que notre code java
est souvent beaucoup plus auto documenté. Je proposerai donc une
approche par un servlet filter dédié.
35 sur 43 09/06/2010 16:11

Je pressens d'ailleurs que la logique de ce filtre va se complexifier

(limitation du nombre de locales supportées, locale par défaut, stockage
dans une session ou un cookie de la locale choisie, filtrage fin des URL à
traiter, etc).
LocaleFilter
Voici une ébauche d'un LocaleFilter qui reposerait sur un forward

server-side (plutôt qu'un 302 redirect) :
public class LocaleFilter implements Filter {
private String defaultLocale;

private Set<String> supportedLocales;
@Override
public void doFilter(ServletRequest req, ServletResponse response, FilterC
if (req instanceof HttpServletRequest) {
HttpServletRequest request = (HttpServletRequest) req;
String locale = String.valueOf(request.getParameter("locale")).toL

if (!supportedLocales.contains(locale)) {
locale = defaultLocale;
}
String to;
if (request.getPathInfo() == null) {
to = "/" + locale + request.getServletPath();
} else {
to = "/" + locale + request.getServletPath() + request.getPath
}
request.getRequestDispatcher(to).forward(request, response);
} else {
chain.doFilter(req, response);
}
}
@Override
public void init(FilterConfig filterConfig) throws ServletException {
// TODO : code real implementation
defaultLocale = "fr";
supportedLocales = new HashSet<String>(Arrays.asList("fr", "en"));
}
...
}
Cyrille (Xebia)
Le 17 mai 2010 à 10:39 (), Jean a dit :
36 sur 43 09/06/2010 16:11

Bonjour,
Merci pour la qualité de vos réponses.
J'ai testé la méthode de Cyrille, j'obtiens cependant une erreur 404:
ERROR RequestProcessor:664 - Invalid path /fr/index was requested
Pour info, j'utilise Le framework struts pour l'internationalisation.
Cdt
@Jean,
Navré mais moi ça marche avec Tomcat 6.0.26 et une jsp de test "toto.jsp"
.
Quelle URL avez vous invoqué ? N'est-elle pas traitée par Struts qui cherche
une action enregistrée en "/fr/index.do" qui n'existerait pas ? N'auriez-vous
pas appelé "/" qui votre configuration "web.xml" redirigerait vers le
welcome-file "index.do" ?
Le message d'erreur dont vous nous parlez "RequestProcessor- Invalid path

... was requested" fait penser à une erreur Struts.
Votre problème me fait penser au "filtrage fin des URL à traiter" que j'ai
évoqué précédemment
> Pour info, j'utilise Le framework struts pour l'internationalisation.
Vous semblez utiliser Struts en conjonction avec votre système par

répertoire "/fr/", "/en/", ... Faire cohabiter deux systèmes ajoute en
complexité
Bon courage,
Cyrille
@Jean,
Remarque complémentaire : il doit être plus simple de n'intercepter d'abord

que les jsp entrantes avec le LocaleFilter, d'exclure les appels aux actions
"*.do" (en ne filtrant que "*.jsp") et d'exclure les forward/include internes à
Struts pour afficher les vues (en limitant le dispatcher à REQUEST).
37 sur 43 09/06/2010 16:11

<web-app ...>
<filter>
<filter-name>LocaleFilter</filter-name>
<filter-class>LocaleFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LocaleFilter</filter-name>
<url-pattern>*.jsp</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
</web-app>
Cyrille (Xebia)
Le 17 mai 2010 à 14:19 (), Jean a dit :
Mes urls sont traitées par struts. la configuration "web.xml" redirige vers le
welcome-file "index.do".
Et l'action recherchée dans mon struts-config est définie comme suit
Pour votre dernière remarque, si j'exclus les appels aux actions "*.do", le
LocaleFilter ne pourra pas s'appliquer
@Jean,
Votre commentaire semble avoir été tronqué, probablement un fragment

XML qui a été avalé.
Votre approche "/mapage.do?locale=fr" => "/fr/mapage.do" doit aussi

s'appliquer à la welcome page :
"/?locale=fr" => "/index.do?locale=fr" => "/fr/index.do"
Cyrille (Xebia)
Le 17 mai 2010 à 16:34 (), Jean a dit :
Alors,
Toutes mes actions strust sont interceptées et traitées par le LocaleFilter.

Le paramètre de la langue est rajoutée dans le request du user (methode
doFilter).
Mais les urls ne sont pas réécrites sous le format /fr/mapage.do ou
/en/mapage.do.
Et je dois aussi dupliquer chaque action dans struts-config pour avoir les
deux langues.Pas terrible et pire encore si je passe à plusieurs langues.
38 sur 43 09/06/2010 16:11

Je pense que j'ai loupé pas mal de chose.

Merci pour votre éclaircissement.
Cdt
Le 18 mai 2010 à 16:28 (), toty a dit :
Bonjour,
Merci pour votre réponse.
Concernant la configuration du mod_loadbalancer.

Par contre je suis confronté à un problème de maintient de session.
Je constate bien un fonctionnement de type RR(Round Robin) pour chaque

requête apache.
Le souci est que au niveau de la l'application nous n'arrivons plus à nous

connecter, puisque apache va interroger un autre tomcat.
Est-possible avec apache de maintenir une session où est-ce au niveau de

l'application de palier le fonctionnement du loadbalancing ?
Cdl.
Toty
@Toty,
j'ai l'impression que vous avez oublié un paramètre important dans votre
configuration du load balancer.
Pour rappel Cyrille vous a fourni un exemple :
Proxy balancer://my-application-cluster>
BalancerMember ajp://node-1:8009 route=node-1 disablereuse=On
# ...
BalancerMember ajp://node-n:8009 route=node-n disablereuse=On
ProxyPass /my-application balancer://my-application-cluster/my-application

stickysession=JSESSIONID
Dans la ligne ProxyPass il faut absolument préciser le

stickysession=JSESSIONID sans quoi apache ne reconnaîtra pas les sessions
Tomcat et distribuera les requêtes en round robin sans se soucier de la
session. Ce paramètre permet à Apache de servir les requêtes d'une même
session vers le même serveur Tomcat en backend.
J'espère vous avoir éclairé,
bien cordialement,
Séven (Xebia)
39 sur 43 09/06/2010 16:11

Le 19 mai 2010 à 11:05 (), Jean a dit :
Bonjour,
J'ai essayé plusieurs fois mais je n'arrive toujours pas réécrire mes urls
sous le format http://monsite/fr/mapage.do. au lieu de http://monsite
/mapage.do?locale=fr. J'étais parti sur apache avec mod_rewrite mais il
parait que c'est mieux de le gérer dans la web application.
Pouvez vous me donner quelques piste svp?
Merci d'avance
Bonjour Jean,
Cyrille vous aidera sûrement sur la partie côté webapp. De mon côté j'ai une
solution fonctionnelle en mod_rewrite à vous de tester :
RewriteEngine on
RewriteRule ^([a-z]+)/(.*)\.do$ $2.do?locale=$1 [QSA,L]
En attendant, le support de cyrille, j'espère que cela pourra vous

débloquer.
Bien cordialement,
Séven.
@Jean,
J'imagine l'approche suivante :

1. des URLs non localisées dans le browser de l'internaute (e.g.
"/mapage.do")
2. gérées par des actions Struts non localisées (e.g. MonAction )
3. action Struts qui utilisentdes vues localisée en faisent des forward vers
des jsp dont le chemin sur le file system est du type /fr/mapage.jsp,
/en/mapage.jsp, etc
Ce fonctionnement me rappelle les thèmes de Spring MVC (1).
Ce raisonnement prend pour hypothèse que l'internaute ne voit pas la locale

dans les urls invoquées avec son browser. Sinon, il faut faire une redirection
302 mais alors le request processor de Struts aura besoin de gérer autant
d'action qu'il y a de locale ...
Cyrille
(1) http://static.springsource.org/spring/docs/3.0.2.RELEASE/spring-
framework-reference/html/mvc.html#mvc-themeresolver
40 sur 43 09/06/2010 16:11

Le 19 mai 2010 à 17:06 (), Jean a dit :
Je vous remercie pour vos réponses.

Je suis pour l'instant la solution apache.
Mais le RewriteRule ne marche pas.
- Il ne devrait pas y avoir une RewriteCond?
- Faut-il inverser ce deux paramètres ( RewriteRule ancienUrl newUrl )
parce que dans votre exemple on a ( RewriteRule newUrl ancienUrl)?
- Faut-il ajouter http://%{HTTP_HOST} dans le second paramètre (newUrl )
du RewriteRule?
Bien cordialement,
Jean
Le 19 mai 2010 à 20:11 (), toty a dit :
@seven,
Merci effectivement cela marche très bien, j'avais tenté d'essayer de mettre
l'option failover.
Savez-vous dans quels cas et à quoi sert cette option? car sur le site
d'apache il indique que l'option est à utiliser lorsque notre backend et notre
front possède un firewall entre ?
Cordialement,
Toty
J'avoue être assez surpris que la RewriteRule ne fonctionne pas car je l'ai
testé en local sur un apache 2.0 .
Attention, la RewriteRule garantie qu'apache convertisse les requêtes
entrantes vers la nouvelle URL typiquement :
Utilisateur -> (Apache) /fr/mapage.do -> (Tomcat) /mapage.do?locale=fr
Apache n'est pas responsable de convertir les URLs fournies par la page
générée ccôté Tomcat. Il faut donc que la page web expose des URL
compatibles avec la règle de conversion:
<a href="/fr/mapage.do" rel="nofollow">mapage</a>
Pour confirmer, vous pouvez commencer par tester l'url directement dans
votre navigateur http://localhost/fr/mapage.do pour vérifier que la page est
affiché avec la bonne locale.
Côté Apache il faudra aussi vous assurer que la RewriteRule soit bien
appliquée pour le contexte correspondant.
41 sur 43 09/06/2010 16:11

Je reste à votre disposition pour plus d'éclaircissements.

Séven.
L'option nofailover du mod_proxy permet simplement de désactiver les

tentatives d'accès sur un autre serveur du balancer en cas d'indisponibilité
d'un worker. En clair comme il est dit dans la documentation Apache, si
vous n'avez pas de réplication de session, l'option nofailover doit-être placée
à "on" pour casser la session en cas d'indisponibilité du serveur qui
hébergeait la session. L'utilisateur devra donc obtenir une nouvelle session
sur un autre serveur.
Séven.
Le 20 mai 2010 à 16:22 (), Jean a dit :
J'ai essayé cette règle et ça marche

RewriteRule ([a-z]+)/(.*)\.do$ /$2.do?locale=$1[QSA,L]
Comment faire pour les urls qui contiennent aussi d'autres paramètres en
plus . ( http://monsite/mapage.do?param1=val1&locale=fr ou encore
http://monsite/mapage.do?param1=val1&param2=val2&locale=en.
je ne veux réécrire que le param de la langue.
Cdt
@Jean,
Eh bien, il n'y a rien de plus à faire que d'ajouter vos paramètres comme à
votre habitude, ils seront reçus normalement du côté Tomcat.
C'est le rôle du drapeau QSA en fin de ligne de la RewriteRule, cela indique
simplement à Apache d'ajouter à l'URL convertie les paramètres reçus en
entrée.
Séven.
Le 27 mai 2010 à 23:44 (), hanan a dit :
je veux votre aide pour faire gestion de client( supprimer , ajouter,modifier

et supprimer avec deux methode servlet et restmodifiable par j2ee)
Laisser un commentaire
Nom (requis)
42 sur 43 09/06/2010 16:11

E-mail (ne sera pas publié) (requis)
Site Web
Valider le commentaire
Tenez moi informé des nouveaux commentaires par e-mail
« Ma rencontre avec Ken Schwaber

Just DeployIt ! »
Xebia IT Architects SAS France

La Défense Colisée - 10/12 Avenue de L'Arche
92419 Courbevoie Cedex
Tél : +33 (0)1 46 91 76 16

Fax : +33 (0)1 46 91 88 00
E-mail : info@xebia.fr
43 sur 43 09/06/2010 16:11

Loadbalancing

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Loadbalancing

Diunggah oleh

Hak Cipta:

Format Tersedia

Tomcat load balancing – mod_proxy vs mod_jk le m... http://blog.xebia.fr/2010/02/03/tomcat-load-balanci...

Blog Xebia France

« Ma rencontre avec Ken Schwaber

Une passion, la technologie.

Imaginez un environnement de travail qui valorise l'innovation

Imaginez un groupe où vous aurez l'opportunité de travailler et partager

Imaginez une culture et des valeurs en rupture avec les SSII.

Imaginez une société où vos talents et vos idées seront reconnus et

1 sur 43 09/06/2010 16:11

N'imaginez plus, vivez-le !

N'hésitez pas à nous contacter à travers le Formulaire de contact ou

2 sur 43 09/06/2010 16:11

3 sur 43 09/06/2010 16:11

4 sur 43 09/06/2010 16:11

Tomcat load balancing – mod_proxy vs mod_jk le

protocole est né pour faciliter et accélérer les communications entre un serveur

En 1999, Sun offre son implémentation de référence des Servlets à la fondation

5 sur 43 09/06/2010 16:11

La création d'AJP résulte donc de la simplicité et de la rapidité de

Le mod_proxy fait partie de la distribution standard d'Apache HTTPD. Il est livré

6 sur 43 09/06/2010 16:11

load-balancing. Nous ne nous intéresserons ici qu'à la configuration d'Apache

mod_proxy_http & mod_proxy_balancer

La configuration du mod_proxy consiste d'abord à s'assurer que les modules

Configuration avec mod_proxy_http & mod_proxy_balancer - httpd.conf

# STATUS AND MONITORING

Vous pouvez le constater, la configuration est parfaitement intégrée à la

7 sur 43 09/06/2010 16:11

configuration standard d'Apache HTTPD. Les équipes de production n'auront à

La première étape consiste à configurer le serveur Apache pour qu'il utilise le

Configuration avec mod_jk - httpd.conf

LoadModule jk_module libexec/apache2/mod_jk.so

# MOD_JK CONFIGURATION FILE

# MOD_JK PROPRIETARY LOG FILE

# NEEDED ON MAC SNOW LEOPARD

# STATUS AND MONITORING

Il faut maintenant configurer le mod_jk proprement dit dans son fichier de

8 sur 43 09/06/2010 16:11

# WORKERS AND PSEUDO WORKER

# STATUS AND MANAGEMENT PSEUDO WORKER

# LOAD BALANCER PSEUDO WORKER

Avec ses deux fichiers de configurations séparés et la syntaxe "rustique" du

9 sur 43 09/06/2010 16:11

Outre le suivi des statistiques du load-balancer, le Balancer Manager permet

10 sur 43 09/06/2010 16:11

La mince différence vient probablement de la jeunesse de la solution de

LoadBalancing et gestion d'erreur

Par requête : la charge est répartie pour chaque requête entrante en

11 sur 43 09/06/2010 16:11

Côté répartition de charge, mod_jk apporte un dernier algorithme de répartition

Pour le reste, le mod_proxy colle au fonctionnement du mod_jk, ce qui ne

Exploitation et diagnostic des problèmes

12 sur 43 09/06/2010 16:11

Un autre atout de mod_proxy est la facilité de diagnostic. N'importe quel acteur

A nos yeux, avec l'intégration native de mod_proxy_http et

Attention, la recommandation de Tomcat est encore le mod_jk et, il est important

13 sur 43 09/06/2010 16:11

Mots-clefs :Load Balancer, Reverse Proxy, Tomcat

Billets sur le même thème :

Tomcat : Adresse IP de l’internaute, load balancer, reverse proxy et header

Auteur : Cyrille Le Clerc et Séven Le Mesle

64 réponses à “Tomcat load balancing – mod_proxy vs mod_jk le

Le 3 février 2010 à 22:46 (), Henri Gomez a dit :