6
votes

Mysql / hibernate a de manière aléatoire "Échec de la liaison de communication"

Nous avons une webapp en cours d'exécution Hibernate / C3PO 4.1.4.Finale, Jetty, Java 6 et MySQL 5.1.63.

javax.persistence.persistenceException: org.hibernate.exception.jdbcconnectionException: Lien de communication échec

Le dernier paquet reçu avec succès du serveur était de 238 519 il y a des millisecondes. Le dernier paquet envoyé avec succès au serveur était 0 millisecondes il y a.

Notre section de propriétés de persistance.xml ressemble à ceci ... xxx

Notre délai d'attente sur MySQL est défini sur 600 secondes. Nous n'avons aucune idée de la façon dont cela se passe 1/5 fois. Le serveur a très peu de charge, la base de données est relativement petite, les servlets fonctionnent tous en quelques secondes.

Quelqu'un a des idées?


4 commentaires

Y a-t-il un problème dans la communication entre Ordinateurs Hosting Jetty et MySQL? Une sorte de pare-feu?


Quelles sont les transactions que vous faites pour causer un tel cas? Combien de temps durent-ils? S'ils durent plus que le délai d'attente MySQL, essayez de casser la transaction vers plusieurs transactions par lots. Sources: été là, faites cela (si tel est le cas, ce que j'ai décrit :))


Tout d'abord votre mySQL opérationnel? et ce paramètre est-il pointé vers l'URL correcte -rp.config.db.url?


Oui, MySQL est opérationnel et travaille. Nous sommes en mesure de passer des appels à 95% du temps mais 5%, il tombera de manière aléatoire.


3 Réponses :


0
votes

Nous avons également fait face au même problème sur le serveur de production. Par défaut, MySQL réinitialise les connexions dans toutes les 8 heures et nous avons donc obtenu une défaillance de la communication dans presque toutes les 8 heures, car nous accédions de manière continue à la base de données avec des travaux planifiés. Nous l'avons résolu en augmentant «wait_timeout» à 14 jours et, comme notre maintenance est planifiée tous les 15 jours, nous redémarrons que chacun de MySQL Server est notre cluster de base de données (nous avons une réplication Master-Master en place). Avec une approche, nous n'avons aucune défaillance de la liaison de communication après cela. En fait, quelque temps, nous ne redémarrons pas le serveur dans tous les 15 jours, mais toujours aucune erreur (toucher le bois). :) Selon votre description, il semble que vous ayez défini wait_timeout d'être 10 minutes, alors je suppose que vous obtiendriez les erreurs avec une différence de temps d'environ 10 minutes. Veuillez noter qu'il n'est pas nécessaire d'avoir à cette erreur sur chaque connexion MySQL réinitialisée après wait_timeout. Ce serait là que si vous accédez à la base de données à cette époque. :)


0 commentaires

3
votes

Cet article explique le correctif. C3P0 ne se reconnecte pas lorsqu'une connexion est expirée.

http://www.databaseandlife.com/automatic-reconnect -from-hibernate-to-mysql /

Il semble totalement fou que les développeurs de Hibernate ne documenteraient pas cela mieux.


0 commentaires