Discussion :

[tchize_]

D'après ce message:

http://lists.agentpp.org/pipermail/s...er/004693.html

ce serait lié à l'implémentation de la jre qui serait assez lente sur la cryptographie. Et effectivement, on constate des tonnes de threads initiant des connexions SSL. Je ne sais pas à quelle vitesse tes services sont censés répondre, mais il faut t'assurer que le LDAP et le CPU soient capable de suivre. On gagnerais aussi à mettre un pool au niveau du ldaptemplate pour limiter la charge SSL.

[Jackysousou]

Voici la configuration du ldaptemplate.

L'OS de la machine du ldap est bien solaris.

Pour ce qui est de l'état des connections réseau, j'attends de reproduire pour vérifier ça.

Je vais aussi voir comment gérer le pool au niveau du ldaptemplate.

Merci pour ton aide.

[Jackysousou]

Ca vient de se reproduire.
Via netstat, toutes les connexion ldap (x9) sont en CLOSE_WAIT...

Les threads continuent de s'accumuler et le CPU dépasse désormais les 60% (6% nominal)

[lunatix]

tu aurais pas un firewall entre ton ldap et ton serveur des fois ?

[Jackysousou]

On vient de me confirmer qu'il n'y en a pas.

[tchize_]

il n'y a pas des masses de connections ldap dans ton netstat. Quand au CLOSE_WAIT, il est normal. L'os garde la connexion un certain temps opur éviter que le port ne soit réutilisé de suite (oui on peux faire certains attaue comme ça pour sefaire passer pour un autre service^^)

Pour le reste, je pense que le problème est à chercher dans le fait qu'il y a trop de connection simultanées au ldap -> le CPU et plus particulièrement le cipher de la jvm ne suivent plus le débit. Le CPU à 60% est un bon indicateur du problème.

[tchize_]

Pour info, la doc sur le pooling ldap dans spring

http://docs.spring.io/spring-ldap/si...l/pooling.html

[Jackysousou]

Ok, merci.
Je regarde ça.