Erreur de passerelle 502 avec Apache mod_proxy et Tomcat

Question

Nous exécutons une application Web sur Tomcat 6 et Apache mod_proxy 2.2.3. Nous voyons beaucoup d'erreurs 502 comme celle-ci :

Passerelle incorrecte ! Le serveur mandataire a reçu une réponse invalide d'un serveur situé en amont.

Le serveur mandataire n'a pas pu gérer la requête GET /la/page.do.

Raison : Erreur de lecture depuis le serveur distant

Si vous pensez qu'il s'agit d'une erreur serveur, veuillez contacter le webmaster.

Erreur 502

Tomcat dispose de nombreux threads, donc il n'est pas limité par les threads. Nous envoyons 2400 utilisateurs via JMeter contre l'application. Toutes les machines se trouvent à l'intérieur de notre pare-feu sur un réseau rapide et non chargé, donc il ne devrait pas y avoir de problèmes réseau.

Quelqu'un a des suggestions de choses à examiner ou à essayer ? Nous nous dirigeons vers tcpdump ensuite.

MISE À JOUR 21/10/08 : Nous n'avons toujours pas résolu cela. Nous ne voyons qu'un très petit nombre de ces erreurs sous charge. Les réponses ci-dessous n'ont pas encore fourni de solution magique...pour l'instant. :)

Answer 1

Juste pour ajouter quelques réglages spécifiques, j'avais une configuration similaire (avec Apache 2.0.63 fonctionnant en reverse proxy sur Tomcat 5.0.27).

Pour certaines URLs, le serveur Tomcat pouvait mettre peut-être 20 minutes à renvoyer une page.

J'ai fini par modifier les paramètres suivants dans le fichier de configuration d'Apache pour éviter que la requête ne dépasse le délai impartit avec son opération de proxy (avec une marge de sécurité importante au cas où Tomcat prendrait plus de temps pour renvoyer une page) :

Timeout 5400
ProxyTimeout 5400

---

Quelques antécédents

ProxyTimeout seul ne suffisait pas. En consultant la documentation pour Timeout, je pense (je ne suis pas sûr) que c'est parce qu'alors qu'Apache attend une réponse de Tomcat, il n'y a pas de trafic entre Apache et le navigateur (ou tout autre client http) - et donc Apache ferme la connexion vers le navigateur.

J'ai remarqué que si je laissais le paramètre Timeout à sa valeur par défaut (300 secondes), alors si la demande mise en proxy vers Tomcat prenait plus de 300 secondes pour obtenir une réponse, le navigateur affichait une page d'erreur "502 Proxy Error". Je crois que ce message est généré par Apache, en sachant qu'il agit en tant que reverse proxy, avant de fermer la connexion vers le navigateur (c'est ma compréhension actuelle - cela peut être incorrecte).

La page d'erreur du proxy indique :

Erreur de proxy

Le serveur proxy a reçu une réponse invalide de la part d'un serveur en amont. Le serveur proxy n'a pas pu traiter la requête GET.

Raison : Erreur de lecture en provenance du serveur distant

... ce qui suggère que c'est le paramètre ProxyTimeout qui est trop court, alors que l'investigation montre que le paramètre Timeout d'Apache (délai entre Apache et le client) influe également sur cela.

Answer 2

Donc, en répondant à ma propre question ici. Nous avons finalement déterminé que nous voyions des erreurs 502 et 503 dans l'équilibreur de charge en raison de l'expiration des threads Tomcat. À court terme, nous avons augmenté le délai d'attente. À plus long terme, nous avons résolu les problèmes de l'application qui provoquaient les délais d'attente en premier lieu. Pourquoi les délais d'attente de Tomcat étaient perçus comme des erreurs 502 et 503 à l'équilibreur de charge reste quelque peu un mystère.

Answer 3

Vous pouvez utiliser proxy-initial-not-pooled

Voir http://httpd.apache.org/docs/2.2/mod/mod_proxy_http.html :

Si cette variable est définie, aucune connexion groupée ne sera réutilisée si la connexion cliente est une connexion initiale. Cela évite le message d'erreur "proxy: error reading status line from remote server" causé par la condition de course selon laquelle le serveur backend a fermé la connexion groupée après la vérification de la connexion par le proxy et avant l'envoi des données par le proxy atteignant le backend. Il faut garder à l'esprit que le réglage de cette variable dégrade les performances, surtout avec les clients HTTP/1.0.

Nous avons également rencontré ce problème. Nous l'avons résolu en ajoutant

SetEnv proxy-nokeepalive 1
SetEnv proxy-initial-not-pooled 1

et en désactivant keepAlive sur tous les serveurs.

mod_proxy_http fonctionne bien dans la plupart des scénarios, mais nous l'utilisons avec une charge importante et nous avons encore quelques problèmes de délai d'attente que nous ne comprenons pas.

Mais vérifiez si la directive ci-dessus répond à vos besoins.

Answer 4

Exemple de configuration apache :

#La valeur par défaut est de 2 minutes
**Timeout 600**
ProxyRequests off
ProxyPass /app balancer://MyApp stickysession=JSESSIONID lbmethod=bytraffic nofailover=On
ProxyPassReverse /app balancer://MyApp
ProxyTimeout 600

    BalancerMember http://node1:8080/ route=node1 retry=1 max=25 timeout=600
    .........

Answer 5

Je suppose que vous utilisez mod_proxy_http (ou équilibreur de charge proxy).

Regardez dans vos journaux tomcat (localhost.log ou catalina.log). Je soupçonne que vous voyez une exception dans votre pile web remonter et fermer le socket auquel le worker tomcat est connecté.