4 votes

Philipp avatar

IOException : La lecture de la socket a échoué avec Apache 2, mod_jk et Tomcat sur AJP

Demandé el 16 de Mai, 2012
Quand la question a-t-elle été
17727 affichage
Nombre de visites la question a
2 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Je reçois l'exception suivante de temps en temps lorsque mes utilisateurs se connectent avec leurs appareils Android au service JSON Rest :

java.io.IOException: Socket read failed
       at org.apache.coyote.ajp.AjpProcessor.read(AjpProcessor.java:313)
       at org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:364)
       at org.apache.coyote.ajp.AjpProcessor.receive(AjpProcessor.java:331)
       at org.apache.coyote.ajp.AbstractAjpProcessor.refillReadBuffer(AbstractAjpProcessor.java:614)
       at org.apache.coyote.ajp.AbstractAjpProcessor$SocketInputBuffer.doRead(AbstractAjpProcessor.java:1065)
       at org.apache.coyote.Request.doRead(Request.java:422)
       at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:290)
       at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:431)
       at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:315)
       at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:200)
       at org.codehaus.jackson.impl.ByteSourceBootstrapper.ensureLoaded(ByteSourceBootstrapper.java:340)
       at org.codehaus.jackson.impl.ByteSourceBootstrapper.detectEncoding(ByteSourceBootstrapper.java:137)
       at org.codehaus.jackson.impl.ByteSourceBootstrapper.constructParser(ByteSourceBootstrapper.java:197)
       at org.codehaus.jackson.JsonFactory._createJsonParser(JsonFactory.java:542)
       at org.codehaus.jackson.JsonFactory.createJsonParser(JsonFactory.java:389)
       at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1454)
       at org.springframework.http.converter.json.MappingJacksonHttpMessageConverter.readInternal(MappingJacksonHttpMessageConverter.java:124)
       at org.springframework.http.converter.AbstractHttpMessageConverter.read(AbstractHttpMessageConverter.java:153)
       at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.readWithMessageConverters(HandlerMethodInvoker.java:641)
       at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.resolveRequestBody(HandlerMethodInvoker.java:605)
       at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.resolveHandlerArguments(HandlerMethodInvoker.java:354)
       at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:171)
       at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:436)
       at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:424)
       at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:923)
       at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:852)
       at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:882)
       at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:789)

Je cours

  • Apache/2.2.20
  • mod_jk 1.2.36
  • Tomcat 7.0.27

Cela pourrait-il être lié à un délai d'attente ? Par exemple, le client ferme la connexion et le serveur n'est plus en mesure de lire sur le socket ? Ou s'agit-il plutôt d'un problème de configuration du serveur ?

UPDATE :

En faisant un peu de awk dans le journal d'Apache, j'ai trouvé les lignes suivantes du journal d'Apache correspondant à ces exceptions du journal de Tomcat :

192.186.30.116 - - [25/Jun/2012:10:47:14 +0200] "POST /myapp/methodX HTTP/1.1" 400 145 "-" "clientApp BlackBerry9360/7.0.0.530 VendorID/168" 10012655 
192.186.30.120 - - [25/Jun/2012:10:53:13 +0200] "POST /myapp/methodY HTTP/1.1" 400 145 "-" "clientApp BlackBerry9800/6.0.0.668 VendorID/124" 10012164 
192.186.30.116 - - [25/Jun/2012:10:53:36 +0200] "POST /myapp/methodZ HTTP/1.1" 400 145 "-" "clientApp BlackBerry9360/7.0.0.530 VendorID/168" 10012677 
192.82.68.16 - - [25/Jun/2012:11:22:31 +0200] "POST /myapp/methodX HTTP/1.1" 400 145 "-" "clientApp BlackBerry9930/7.1.0.402 VendorID/104" 10012667 
192.82.68.16 - - [25/Jun/2012:11:23:21 +0200] "POST /myapp/methodZ HTTP/1.1" 400 145 "-" "clientApp BlackBerry9930/7.1.0.402 VendorID/104" 10012562

Vous pouvez voir le code de statut 400 Bad Request envoyé aux clients pour ces demandes.

Les grands chiffres à la fin de la ligne (par exemple 10012562) indiquent le nombre d'heures de travail. l'heure à laquelle la demande a été traitée sur le serveur en microsecondes : 10012562 = environ 10 secondes

Il semble que la connexion soit interrompue au bout de dix secondes ? J'ai regardé dans la configuration AJP mais il n'y a pas de timeout défini - 10 secondes serait le timeout pour les requêtes asynchrones que je n'utilise pas.

Demandé el 16 de Mai, 2012 par Philipp

Réponses

Trop de publicités?

3voto

Philipp avatar
Philipp Points 101

J'ai trouvé la raison. Le problème est dû à la configuration par défaut du module Apache mod_reqtimeout :

<IfModule reqtimeout_module>

# mod_reqtimeout limits the time waiting on the client to prevent an
# attacker from causing a denial of service by opening many connections
# but not sending requests. This file tries to give a sensible default
# configuration, but it may be necessary to tune the timeout values to
# the actual situation. Note that it is also possible to configure
# mod_reqtimeout per virtual host.

# Wait max 20 seconds for the first byte of the request line+headers
# From then, require a minimum data rate of 500 bytes/s, but don't
# wait longer than 40 seconds in total.
# Note: Lower timeouts may make sense on non-ssl virtual hosts but can
# cause problem with ssl enabled virtual hosts: This timeout includes
# the time a browser may need to fetch the CRL for the certificate. If
# the CRL server is not reachable, it may take more than 10 seconds
# until the browser gives up.
RequestReadTimeout header=20-40,minrate=500

# Wait max 10 seconds for the first byte of the request body (if any)
# From then, require a minimum data rate of 500 bytes/s
RequestReadTimeout body=10,minrate=500

</IfModule>

Je suppose que les clients BlackBerry ont été plus durement touchés parce que l'envoi du corps de la requête via l'infrastructure BIS de RIM prend plus de temps.

Réglez la valeur à 100 secondes et vérifiez si les clients sont toujours affectés.

Répondu el 2 de Juillet, 2012 par Philipp (101 Points )

0voto

user121989 avatar
user121989 Points 41

Il semble qu'il s'agisse d'un timeout, mais avez-vous essayé (ou est-il possible) d'accéder au service REST directement via Tomcat (sans passer par apache/ajp). Si vous essayez et que vous voyez que vous n'obtenez plus ces exceptions, c'est que peut être un truc d'apache2/mod_jk.

Dans mon précédent emploi, j'ai découvert que certaines versions de mod_jk fonctionnaient mieux avec apache2 (bien sûr, nous n'avons pas vraiment fait de test strict, nous avons simplement utilisé les versions qui semblaient fonctionner partout sans les modifier car ce n'était pas nécessaire).

Répondu el 23 de Mai, 2012 par user121989 (41 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X