httpd-users-de mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tino Strauss <tino.stra...@t-systems.com>
Subject falsche content-length und mod_jk - haengende Verbindungen
Date Thu, 27 Feb 2003 15:54:42 GMT
Hallo,

folgendes habe ich schon erfolglos in 
de.comm.infosystems.www.unix.servers gepostet, leider erfolglos.  
Moeglicherweise kennt ja hier einer das beschriebene Szenario und weiss 
Rat:

Plattform: SunOS 5.8

mod_ssl 2.8.12
Apache 1.3.27
mod_jk 1.2.2
Tomcat 4.0.4

Clients uebermitteln mittels POST-Request Daten an ein Servlet im 
Tomcat, die Verbindung Client <-> Apache laeuft ueber SSL mit 
Clientauthentifizierung. Das funktioniert auch praechtig, bis Clients 
Anfragen mit zu grosser Content-Length (mehr als Daten im Body sind) 
stellen. Die betreffende Verbindung bleibt bestehen, solange auch der 
CLient sie aufrecht erhaelt, allerdings kommen im Tomcat auch keine 
Daten an. Die Verbindung bleibt offensichtlich in mod_jk haengen.

Mit genuegend solcher Anfragen gehen irgendwann die Ressourcen 
zur Neige und der Apache beginnt 'gesunde' Requests abzuweisen, bis die 
kaputten Clients ihre Verbindungen abbrechen.

Der timeout-Parameter aus der httpd.conf scheint hier keine Wirkung zu 
zeitigen (bei Anfragen die nicht durch mod_jk gehen funktionierts).

Es scheint, dass mod_jk beim Aufruf von ap_client_get_block (Apache-API) 
blockiert.


Letztendlich bleiben wohl folgende Moeglichkeiten:

- SunOS ist falsch konfiguriert, so dass nichtblockierendes Lesen nicht 
möglich ist  -> hmm... kommt das vielleicht jemandem bekannt vor?

- mod_jk initialisiert/verwendet die Apache-API falsch -> erscheint auch 
nicht wirklich wahrscheinlich, eine falsche content-length ist eine so 
offensichtliche Fehlermoeglichkeit (IIRC gabs sowas auch frueher mal 
mit alten Netscapes)

- Apache-Bug -> siehe letzter Punkt

- Fehler in der Kompilierungsoptionen von Apache/mod_jk

- Konfigurationsfehler -> wie gesagt die Timeoutoption funktioniert, 
wenn mod_jk nicht involviert ist


Achso hier waeren noch Logausgaben von mod_jk (debug):

hier bleibst haengen:
[jk_uri_worker_map.c (460)]: Into jk_uri_worker_map_t::map_uri_to_worker
[jk_uri_worker_map.c (477)]: Attempting to map URI '/####/adapter'
[jk_uri_worker_map.c (502)]: jk_uri_worker_map_t::map_uri_to_worker, 
Found a context match ajp13 -> ####
[jk_worker.c (132)]: Into wc_get_worker_for_name ajp13
[jk_worker.c (136)]: wc_get_worker_for_name, done  found a worker
[jk_ajp_common.c (1355)]: Into jk_worker_t::get_endpoint
[jk_ajp_common.c (1079)]: Into jk_endpoint_t::service
[jk_ajp_common.c (280)]: Into ajp_marshal_into_msgb
[jk_ajp_common.c (413)]: ajp_marshal_into_msgb - Done
[jk_ajp_common.c (613)]: sending to ajp13 #306
[jk_ajp_common.c (854)]: ajp_send_request 2: request body to send 1000 - 
request body to resend 0


und hier bricht der Client ab:
[jk_ajp_common.c (613)]: sending to ajp13 #777
[jk_ajp_common.c (699)]: received from ajp13 #3
[jk_ajp_common.c (613)]: sending to ajp13 #4
[jk_ajp_common.c (699)]: received from ajp13 #41
[jk_ajp_common.c (462)]: ajp_unmarshal_response: status = 503
[jk_ajp_common.c (467)]: ajp_unmarshal_response: Number of headers is = 
1
[jk_ajp_common.c (507)]: ajp_unmarshal_response: Header[0] 
[Content-Type] = [text/html]
[jk_ajp_common.c (699)]: received from ajp13 #637
[jk_ajp_common.c (699)]: received from ajp13 #2
[jk_ajp_common.c (1333)]: Into jk_endpoint_t::done, recycling connection


Danke fuer eure Aufmerksamkeit!

	Tino
	

--------------------------------------------------------------------------
                Apache HTTP Server Mailing List "users-de" 
      unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
           sonstige Anfragen an users-de-help@httpd.apache.org
--------------------------------------------------------------------------


Mime
View raw message