Erreur de proxy 502 «Raison: erreur de lecture du serveur distant» avec Apache 2.2.3 (Debian) mod_proxy et Jetty 6.1.18

Apache reçoit les demandes au port 80 et les envoie à Jetty au port 8080

The proxy server received an invalid response from an upstream server
The proxy server could not handle the request GET /.

Mon dilemme: Tout fonctionne très bien normalement (demandes rapides, quelques secondes ou quelques dizaines de secondes demandes longues sont traitées ok ). Des problèmes surviennent lorsque le traitement d'une demande prend beaucoup de temps (quelques minutes?).

Si j'émets la demande directement à Jetty au port: 8080, la demande est traitée correctement. Donc, le problème est susceptible de se situer quelque part entre Apache et Jetty où j'utilise mod_proxy . Comment résoudre ceci?

J'ai déjà essayé quelques "astuces" relatives aux paramètres KeepAlive, sans succès. Voici ma configuration actuelle, des suggestions?

#keepalive Off                     ## I have tried this, does not help
#SetEnv force-proxy-request-1.0 1  ## I have tried this, does not help
#SetEnv proxy-nokeepalive 1        ## I have tried this, does not help
#SetEnv proxy-initial-not-pooled 1 ## I have tried this, does not help
KeepAlive 20                       ## I have tried this, does not help
KeepAliveTimeout 600               ## I have tried this, does not help
ProxyTimeout 600                   ## I have tried this, does not help

NameVirtualHost *:80
<VirtualHost _default_:80>
    ServerAdmin webmaster@mydomain.fi

    ServerName www.mydomain.fi

    ServerAlias mydomain.fi mydomain.com mydomain www.mydomain.com

    ProxyRequests On
    ProxyVia On
    <Proxy *>
            Order deny,allow
            Allow from all
    </Proxy>

    ProxyRequests Off
    ProxyPass / http://www.mydomain.fi:8080/ retry=1 acquire=3000 timeout=600
    ProxyPassReverse / http://www.mydomain.fi:8080/

    RewriteEngine On
    RewriteCond %{SERVER_NAME} !^www\.mydomain\.fi
    RewriteRule /(.*) http://www.mydomain.fi/$1 [redirect=301L]

    ErrorLog /var/log/apache2/error.log

    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn

    CustomLog /var/log/apache2/access.log combined
    ServerSignature On

</VirtualHost>

Voici également le journal de débogage d'une requête en échec:

74.125.43.99 - - [29/Sep/2010:20:15:40 +0300] "GET /?wicket:bookmarkablePage=newWindow:com.mydomain.view.application.reports.SaveReportPage HTTP/1.1" 502 355 "https://www.mydomain.fi/?wicket:interface=:0:2:::" "Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10"
[Wed Sep 29 20:20:40 2010] [error] [client 74.125.43.99] proxy: error reading status line from remote server www.mydomain.fi, referer: https://www.mydomain.fi/?wicket:interface=:0:2:::
[Wed Sep 29 20:20:40 2010] [error] [client 74.125.43.99] proxy: Error reading from remote server returned by /, referer: https://www.mydomain.fi/?wicket:interface=:0:2:::

J'ai résolu le problème. Le Keepalive=Ondevrait être inséré dans la ProxyPassligne de configuration:

ProxyPass / http://www.dom.fi:8080/ retry=1 acquire=3000 timeout=600 Keepalive=On

Regarde ça

Keepalive=On

Là? C'est critique ;)

Avez-vous essayé de mettre setenv proxy-initial-not-pooled 1?

Référence ici

Cette erreur peut également se produire si vous ne terminez pas votre URL de proxy avec un /. Les deux chemins doivent se terminer par un /ou aucun.

En regardant le journal, il y a quelque chose qui expire au bout de 5 minutes (= 300 secondes). C'est assez long d'attendre une réponse. Lorsque vous accédez directement au serveur Jetty, cette ressource est-elle si longue à produire une réponse?

Si les cinq minutes sont vraiment dans les temps de réponse possibles, vous pouvez essayer de peaufiner la directive de configuration ProxyTimeout.

En fonction de la configuration de votre réseau, il se peut qu’il n’y ait aucune raison d’essayer même d’utiliser un système keepalive (existe-t-il un pare-feu entre le serveur d’applications et le proxy pouvant être configuré pour abandonner trop longtemps les sessions inactives?) , mais ProxyTimeout affecterait le comportement du proxy lui-même.

Si le même proxy sert également d'autres serveurs, il serait préférable de conserver le ProxyTimeout actuel et de configurer le délai d'expiration dans la directive ProxyPass (voir la documentation de mod_proxy).

Si, toutefois, les réponses sans proxy sont toujours nettement inférieures aux cinq minutes (voir limite limite), il se peut qu'il y ait une certaine interférence entre le proxy et le serveur d'applications, mais vous ne fournissez rien. valeur pour identifier ce que cela pourrait être.

Pour moi, la suppression d'une valeur d'en-tête appelée Transfer-Encoding" (binary)dans mon application serveur (PHP) a résolu le problème pour:

[proxy_http: erreur] [pid 17623] (22) Argument non valide: [client 127.0.0.1:44929] AH01102: erreur lors de la lecture de la ligne d'état du serveur distant 0.0.0.0:80

Toutes les autres suggestions aiment SetEnv proxy-initial-not-pooledou Keep-Aliven'ont pas.

Si les solutions ci-dessus ne fonctionnent pas, vous pouvez essayer d’activer tous vos modules Apache pour vous assurer qu’il n’ya pas un module dont vous avez besoin qui a été désactivé par inadvertance.

Par exemple, la cause de mon problème était de remplacer toutes les instances de #LoadModule par LoadModule dans tous mes fichiers de configuration Apache. Puisque cela a résolu le problème pour moi, je savais donc que mon problème n'était pas un argument de directive "KeepAlive" manquant, mais plutôt un problème de dépendance manquante.

Car, rappelez-vous, les fichiers .so sont essentiellement des bibliothèques statiques. Avoir un module activé ne signifie pas qu'il sera utilisé, mais en avoir un désactivé signifie qu'il ne peut pas être utilisé. Par conséquent, tout ce qui en dépend échouera nécessairement.

Remarque: cette réponse a reçu quelques votes négatifs en raison du fait que ma réponse initiale semblait suggérer de laisser tous les modules activés, pour toujours. Bien que vous puissiez théoriquement le faire sans rien casser, ce n’est évidemment pas une solution de meilleure pratique.

Alors, s'il vous plaît comprendre, je suggère simplement cela comme une étape de dépannage, pas une solution finale.

Veuillez également noter que j'utilise un projet spécial git pour suivre tous les fichiers de configuration apache de ma machine locale. De cette façon, je peux effectuer ce type d'opérations de recherche et de remplacement globales dans mon répertoire de travail apache config, en tant qu'étape de dépannage. Si l'activation de tous les modules réussit, essayez à nouveau de les désactiver un par un et de redémarrer apache entre-deux, jusqu'à ce que vous trouviez quel module il doit rester activé. Une fois que vous avez compris, remettez le repo dans son état d'origine et activez uniquement le module qui doit rester activé.

Vous constaterez également que l'utilisation de git pour suivre vos fichiers de configuration Apache nettoie ces répertoires, car vous n'avez plus besoin de ces fichiers démodés .bak et .default.