Impasse de la question dans le DBCP déployé sur Tomcat

Je suis en utilisant le DBCP source de données (configuration par défaut), au Printemps de configuration pour gérer mes connexions à la base de données, et je suis en cours d'exécution dans une situation de blocage lorsque le nombre de clients augmenter.

J'ai trouvé qu'il y a un problème de blocage dans le DBCP 1.2.1 qui j'ai été en utilisant, ce qui était censé être résolu dans la version 1.4. J'ai donc mis à niveau vers la version 1.4, mais le problème persiste.

Dans le thread dump, il y a beaucoup de threads bloqués à la suite de trace de la pile sur le dessus:

   java.lang.Thread.State: WAITING on org.apache.commons.pool.impl.GenericObjectPool$Latch@b6b09e
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1104)
at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)
at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
at org.springframework.jdbc.datasource.DataSourceTransactionManager.doBegin(DataSourceTransactionManager.java:200)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:350)
at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:261)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:101)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:160)
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:631)

Toutes les suggestions sont les bienvenues!

  • Je suis confronté à un problème similaire.. avez-vous résoudre ce problème.. pourriez-vous nous donner quelques pointeur si si..
  • Je suis passé à c3p0 trop, a été très heureux avec les fonctionnalités et la stabilité. Je n'ai pas utilisé DBCP depuis, donc je ne peux pas dire si le problème existe encore ou non.
InformationsquelleAutor Iravanchi | 2011-04-19
  1. 8

    Je suis passé à c3p0, quelques années en arrière. Vous pouvez essayer. Je crois que vous n'avez pas besoin de changer, c'est juste un jeu de configuration.

    Quelque peu le sujet, Options de groupement de connexions avec JDBC: DBCP vs C3P0. Eh bien, en fait je l'ai fait liées.

    [édité, 19/10/12]

    Tomcat 7 dispose d'une connexion décente piscine, Le Tomcat Pool de connexions JDBC.

    • Dans le cas de la commutation de pools de connexion, comment jdbc-piscine? DBCP montre de meilleures performances dans les tests de performances par rapport à c3p0, et jdbc-piscine est plus rapide que les deux. Une expérience avec cela?
    • Non, je n'ai jamais utilisé jdbc de la piscine. Par conséquent, ne peut rien dire à ce sujet. Mais après la lecture de ce sujet, il semble prometteur. Comme la mesure de la performance est concerné, ce thread, people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html, suggère que le DBCP est faible dans performances.
    • DBCP est médiocre par rapport à jdbc-piscine, mais cet indice montre c3p0 est plus lent que les deux (mais probablement plus robuste que le DBCP comme vous l'avez dit): tomcatexpert.com/blog/2010/03/22/...
    • Merci pour l'indice de référence, Iravanchi.
    • Dans le cas où quelqu'un lisant cette question, je l'ai passé à c3p0, comme conseillé par @Adeel Ansari, et ne pas avoir de problèmes dans beaucoup de charges plus élevées depuis (ce qui est presque 1,5 ans)
    InformationsquelleAutor Adeel Ansari
  2. 1

    Avez-vous assurez-vous que la chambre des communes-piscine de version correspond à la dbcp version?

    Aussi, je ne vois pas un blocage dans le stacktrace, il ressemble simplement vous avez des threads en attente de connexions pour libérer.. Combien de threads avez-vous essayer de se connecter en même temps? Combien de connexions avez-vous configuré pour la piscine, etc..?

    De débogage dans ce genre de cas, il est également utile de regarder ce que les discussions qui ont eu une connexion sont en train de faire.

    • Les deux sont des versions les plus récentes, DBCP 1.4, PISCINE 1.5.5. Il y a aussi un bug dans la PISCINE 1.5.2 qui montre exactement la même trace que la mienne, et il doit être fixé par 1.5.3. Et je suis en utilisant 1.5.5. Je n'ai pas configuré de la piscine options, de sorte que son utilisation de valeurs par défaut. Nombre de threads sont normalement de 30 à 50 dans l'état normal, mais lorsque l'application des blocages, Tomcat crée un thread pour chaque demande et tous d'entre eux sont bloqués, de sorte qu'il atteigne 150 ou 200 threads.
    • Et TOUS les threads sont en attente de connexion après la condition de blocage. Il n'y a pas d'autres threads activement à faire quoi que ce soit. Tous d'entre eux finit par en arriver au point que ils ont besoin d'une connexion, ils sont dans une file d'attente qui ne se déplace jamais en avant.
    • Ok alors, êtes-vous sûr que vous êtes en train de retourner les connexions à la piscine aussi?
    • Absolument. Je suis l'aide de Printemps aspects dans une configuration simple (vous pouvez voir l'effet dans la trace de la pile). Et ce n'est pas un problème dans un bas-simultanéité de réglage (avec 10 ou 20 utilisateurs). J'ai même écrit un débogage filtre à compter d'ouverture/de fermeture dans chaque fil et vérifiez s'il ya une fuite.
    • Étrange, que le blocage qui se passe réellement lorsque la piscine est épuisé et je n'appellerais pas ça un blocage dans cette situation.. Comment est la connexion de clôture avec le printemps, les aspects traités?
    • Il n'y a pas de fil occupé avec une connexion, et tous les threads sont en attente pour en obtenir un. Je suppose que le problème n'est pas l'épuisement de la piscine. Printemps TX aspect renvoie (ferme) la connexion lors de l'appel de la méthode dessous renvoie en quelque sorte (soit de retour ou de jeter).
    • Je suis encore assez sûr que la situation est tout simplement causé par les connexions de ne pas être retournée à la piscine. Qui ne nécessite pas de n'importe quel thread être fait à l'aide de cette connexion plus. Vous pourriez peut-être vérifier par l'enregistrement de débogage le réel de l'état de la piscine (actif, inactif, etc.. connexions) lorsque le problème est de vivre? Si cela montre que la piscine est vide, je continuerais par le débogage du Printemps TX proche de la logique et de la façon dont il s'applique au type de source de données que vous utilisez.

    InformationsquelleAutor Mikko Wilkman
  3. 1

    Incrasing charge de l'application est de plus en plus besoin de connexions simultanées. Que vos fils sont accrochés sur borrowConnection() - signifie que vous êtes de ne pas avoir suffisamment de ActiveConnections disponibles.

    Incrkease maxActive dans votre source de données des propriétés et définir les WHEN_EXHAUSTED_BLOCK pour un certain temps comme 600ms - 1000ms. Vous obtiendrez No element available exception seulement après avoir écoulé de 600ms -1000 mme.

    • Ce que vous décrivez provoque un ralentissement. J'ai eu un clair de blocage (où les connexions disponibles qui sont retournés à la piscine n'est plus servi) qui s'est manifesté à partir d'un thread dump. Aucun des fils étaient rien faire, tous d'entre eux ont été bloqués par la piscine. Vous devriez lire la question et les réponses plus attentivement avant de poster une réponse.
    InformationsquelleAutor arviarya
  4. 0

    Je pense que c'est dû à la non fermeture des connexions dans votre code d'application, donc vous avez juste à court de connexions dans le pool.
    Peut-être que vous devriez essayer de définir le "removeAbandoned" propriété dans DBCP.
    Ceci est documenté dans http://commons.apache.org/dbcp/configuration.html comme

    Mettre ce paramètre à true pouvez récupérer db connexions à partir d'applications mal écrites
    qui ne parviennent pas à fermer une connexion.

    Bonne chance!

    • Non, le problème n'est pas que la piscine est épuisé. J'ai effectivement créé des wrappers et compté les ouvrir/fermer paires. De Plus, lorsqu'il y a des fuites sur les conduites, c3p0 va bloquer trop, et assez rapide (je l'ai testé). Le thread dump montre clairement que les threads sont bloquées les unes des autres.
    InformationsquelleAutor jcamillo
  5. 0

    J'ai été confronté à des problèmes similaires et cela a été résolu en suivant les étapes

    1. Fermer toutes les ressources de base de données dans le bon ordre 

      resultSet.close();
statement.close();
connection.close();

    Pilotes différents sont mis en œuvre différemment, certains pilotes serait encore la main sur la connexion si le jeu de résultats n'est pas fermé.

    1. Apache DBCP par défaut doit être à l'écoute

    dataSource.setDefaultAutoCommit(true);
    dataSource.setMaxActive(700); //make sure db server has it 800
    dataSource.setRemoveAbandoned(true);
    dataSource.setTestOnBorrow(true);
    dataSource.setLogAbandoned(true);
    dataSource.setTestWhileIdle(true);
    dataSource.setTestOnReturn(true);
    dataSource.setRemoveAbandonedTimeout(60);

    Assurez-vous que serveur de base de données peut permettre à au moins 50+ connecitions plus que le nombre spécifié dans setMaxActive que le dbcp donne x de nouvelles connexions d'abord, puis essayez de nettoyer les connexions dépassant setMaxActive nombre. Sur le nettoyage dbcp montre toutes les connexions n'ont pas été fermés sur le serveur log/console.

    InformationsquelleAutor veer7