Configuration de Tomcat à l'aide de DBCP
Nous obtenons un CommunicationsException (à partir de DBCP) après en divisant pendant un certain temps (quelques heures). Le message d'erreur (Exception) est à la fin de cette question - mais je ne vois pas wait_timeout défini dans l'une quelconque des fichiers de configuration. (Où devons-nous chercher? Quelque part hors de la tomcat/conf répertoire?).
Deuxièmement, comme l'a suggéré l'Exception, où l'on a mis le "Connector/J propriétés de connexion 'autoReconnect=true'"? Voici la définition de la ressource dans le fichier conf/context.xml dans tomcat mis en place:
<Resource name="jdbc/TomcatResourceName" auth="Container" type="javax.sql.DataSource"
maxActive="100" maxIdle="30" maxWait="10000"
removeAbandoned="true" removeAbandonedTimeout="60" logAbandoned="true"
username="xxxx" password="yyyy"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://127.0.0.1:3306/dbname?autoReconnect=true"/>
Troisièmement, pourquoi ne la JVM attendre jusqu'à l'appel à executeQuery() pour lancer l'Exception? Si la connexion a expiré, la méthode getConnection devriez jeter l'Exception, n'est-ce pas? C'est la section du code source je parle:
try {
conn = getConnection (true);
stmt = conn.createStatement (ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
rset = stmt.executeQuery (bQuery);
while (rset.next()) {
....
Enfin, voici la 1ère quelques lignes de la trace de la Pile...
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 84,160,724 milliseconds ago. The last packet sent successfully to the server was 84,160,848 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)
at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1074)
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3291)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1938)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2107)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2642)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2571)
at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1451)
at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208)
Ce sont les raisons pour lesquelles certains d'entre nous pensent "oublier dbcp, il peut être dépendant des IDE configurations et sous le capot de la magie que DriverManager.getConnection(...) peut être plus fiable". Tous les commentaires sur qui? Merci pour vos idées, - MME
OriginalL'auteur Manidip Sengupta | 2011-02-09
Vous devez vous connecter pour publier un commentaire.
Depuis DBCP garde retourné les connexions mysql open pour les prochaines demandes de connexion, ils sont les victimes de la Délai d'expiration du Serveur MySQL.
DBCP a un certain nombre de caractéristiques qui peuvent aider (peut être utilisé en commençant par Tomcat 5.5 IIRC).
La validation permet de s'assurer que la connexion est valide avant de revenir à une webapp de l'exécution de la "emprunter" la méthode. Le drapeau de cours, permet cette fonctionnalité.
Si le délai d'attente (8 heures je crois) est écoulé et que la connexion est morte, alors qu'une nouvelle connexion est testé (si aucun n'est plus, il est créé) et remis à la webapp.
D'autres approches possibles:
utiliser le
testWhileIdle="true"
DBCP dans vos paramètres de ressources également vérifier les connexions inactives avant de façon efficace une demande est détecté.Utiliser le "connectionProperties' pour renforcer votre connexion MySQL (par exemple,
autoReconnect/autoReconnectForPools=true
)1. Votre compréhension est correcte. Toutes les solutions que j'ai indiqué sont complémentaires. D'en organiser un, n'empêche pas les autres. La ceinture et les bretelles sont encore mieux 😉 j'aimerais mettre en œuvre tous les 3 solutions. des tests, alors que d'inactivité signifie moins de temps d'attente à "emprunter" le temps. Configuration des propriétés de l'permettra de réduire les déconnexions intempestives. Oui elles vont toutes dans la partie des Ressources de votre webapp de l'context.xml (plus tard, déployé par tomcat dans $CATALINA_HOME/conf/Catalina/localhost/yourwebapp.xml).
autoReconnect n'est pas recommandé - dev.mysql.com/doc/refman/5.0/en/...
OriginalL'auteur Alain Pannetier
DBCP n'est pas conçu pour l'utilisation dans la production, même si les auteurs disent que (voir cette présentation: http://www.infoq.com/presentations/Tuning-Tomcat-Mark-Thomas).
Je suggère de jeter un oeil à C3P0: http://www.mchange.com/projects/c3p0/index.html
Cette présentation décrit lors de l'utilisation de la BIO et de NIO, en fonction de la durée des séances et de la simultanéité des exigences (Nous sommes faibles sur les deux questions). Un pointeur sur laquelle elle ne devrait pas être utilisé dans la production? Juste à haute fréquence de connexion? Btw, j'ai pris un coup d'oeil à C3P0, semble très intéressant, nous pourrions essayer si DBCP garde qui nous donne des problèmes. Merci pour l'info, - MME
Si je me souviens bien il y a un point dans cette présentation, quand le gars dit "DBCP n'a jamais été conçu pour une utilisation en production" ou quelque chose comme ça. Oui, c'est une aiguille dans une botte de foin, mais je ne pouvais pas oublier qu'après je l'ai entendu.
C3P0 ne prend pas en charge JDBC4 fonctionnalités. Source : sourceforge.net/tracker/...
OriginalL'auteur Spajus