Discussion :

[Jackysousou]

Bonjour,

Depuis plusieurs mois, je me penche régulièrement sur un problème tomcat d’accumulation de thread qui bloque les traitements serveurs jusqu'à ce que le nombre maximum de thread soit finalement atteint que le tomcat soit coupé.


Contexte :

Il s'agit un projet professionnel où l'application est utilisée par une soixantaine d'opérateurs.

Comme tout client lourd, l'application se connecte à un serveur d'application (ici, tomcat) pour effectuer ses requêtes en base de données. Pour cela, il va soit créer un nouveau thread serveur, soit en utiliser un ouvert et disponible.

Le problème survient de manière totalement aléatoire. Il arrive qu'un des traitements se bloque pour une raison X et tous les traitements suivant (donc les nouveaux threads ou les ré-utilisé) ne mettent en mode "wait" et s'accumulent constamment.

Voici une capture d'écran du manager à cet instant :



La première piste, ou pour dire vrai, la seule, qu'on a eu était vis à vis de la base de données. Certaines requêtes pouvaient être longue. On a donc augmenté le nombre maximum de thread actifs, ce qui a été bénéfique pendant plusieurs mois (cf. plus bas, le appContext.xml)
Cette modification a eu pour effet de tuer le thread après une période de X seconde libérant alors les thread suivant, ce qui a empêché de faire tomber le tomcat, mais bloquant les opérateurs le temps de la durée de vie du thread bloquant...


Configuration

Au niveau tomcat, le serveur.xml (cf. pièce jointe)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
 <Service name="Catalina">
 
    <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="200" minSpareThreads="40"/>
 
    <Connector executor="tomcatThreadPool" port="8081" protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="http"
               connectionTimeout="40000" maxHttpHeaderSize="8192" acceptorThreadCount="4" 
               redirectPort="8443" xpoweredBy="false" server="server" allowTrace="false" />
 
...

Au niveau webApp, appContext.xml (cf. pièce jointe)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
  <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
    <property name="driverClassName" value="oracle.jdbc.driver.OracleDriver" />
    <property name="url" value="jdbc:oracle:thin:@${host}:${port}:${database}" />
    <property name="username" value="${database.username}" />
    <property name="password" value="${database.password}" />
    <!--property name="testOnBorrow" value="true" />
    <property name="testWhileIdle" value="true" />
    <property name="validationQuery" value="select 1 from dual" /-->
    <property name="maxWait" value="10000" />
    <property name="maxIdle" value="70" />
    <property name="maxActive" value="-1" />
  </bean>

L'objectif

Au pire, limiter le durée de vie d'un thread tomcat. De façon nominale, les traitements serveurs ne dépassent jamais les 30 secondes. On a essayé d'utiliser de nombreux paramètres, en vain...


Si quelqu'un a la moindre idée, je suis preneur.

Merci

[lunatix]

il faut déterminer quel est le probleme

quand ton application bloque, il faut faire un threaddump de ta jvm
jstack <pid> >> threaddumps.log
(google thread dump java, tu verras y'a plein de methodes : kill -3 etc...)

tu devrais facilement trouver quel est le truc qui bloque. (tu vas surement avoir plein de threads coincés sur la même methode)


Apres tu ne pourras pas (a ma connaissance) limiter la durée du thread au niveau tomcat : il faut travailler coté code de l'application.
Par exemple passer par un executorService qui va executer les appels qui bloquents (on peut facilement mettre un timeout sur un executorservice) et y coller un Semaphore pour empecher d'avoir trop de threads bloqués dans une partie de code
http://docs.oracle.com/javase/6/docs...orService.html
http://docs.oracle.com/javase/6/docs...Semaphore.html

[Jackysousou]

Merci pour ta réponse.

J'ai déjà fait un threaddump, mais l'étude du retour n'a pas été concluant.
De tête, il y avait que des thread en état "waiting"...
J'en referai un demain si je reproduis, et je posterai.

J'essaierai d'intégrer l'executorService et le Semaphore pour tester.

[tchize_]

.
De tête, il y avait que des thread en état "waiting"...

Ben oui, étonnant hein. La question n'est pas trop de savoir qu'ils sont en waiting (ça on en a une bonne idée au départ), la question est "sur quoi?". Tu regarde la ligne de code concernée, tu saura sur quel sémaphore ils attendent, tu regarde dans ton paquet quel est le thread qui possède le sémaphore (typiquement c'est celui qui attends pas au même endroit que les autres), et tu détermine ensuite par analyse du code pourquoi il ne rend pas le sémaphore.

Les raisons peuvent être nombreuses: erreur de programmation sur un sémaphore, un thread qui boucle infini, datasource consommé mais jamais rendu, etc...

[Jackysousou]

Bonjour,

Je n'ai pas pu reproduire le problème ces 2 derniers jours, mais j'ai récupéré le thread dump d'avril, les choses n'ayant pas beaucoup changé...

Après une nouvelle analyse avec l'outil TDA - Thread Dump Analyser, on en est arrivé au même point : un soucis avec les accès hibernate/DB.

Il y a peut être quelque chose qui nous a échappé, je vous lie les threads dump concernés au cas où.

J'attends de reproduire pour un nouveau dump.

Merci.

[ra77]

Bonjour,

Je n'ai pas pu reproduire le problème ces 2 derniers jours, mais j'ai récupéré le thread dump d'avril, les choses n'ayant pas beaucoup changé...

Après une nouvelle analyse avec l'outil TDA - Thread Dump Analyser, on en est arrivé au même point : un soucis avec les accès hibernate/DB.

Il y a peut être quelque chose qui nous a échappé, je vous lie les threads dump concernés au cas où.

J'attends de reproduire pour un nouveau dump.

Merci.

Non il semble bien avoir un problème avec les accès hibernate/DB.

L'étape d'après est de regarder ce qu'il se passe au niveau bdd (requête SQL longue ?) + regarder la valeur du timeout tomcat <-> base de données (peut être faut il en mettre un plus agressif) + regarder la taille du pool de connexion (trop grand ? trop petit ?)