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 [EMAIL PROTECTED]
sonstige Anfragen an [EMAIL PROTECTED]
--------------------------------------------------------------------------
