1. Accueil
  2. Question et réponse
  3. La meilleure façon de déboguer les connexions MySQL qui sont fermées sur moi après ~ 39 minutes?

La meilleure façon de déboguer les connexions MySQL qui sont fermées sur moi après ~ 39 minutes?

2010-10-24 17 views
1

J'ai hibernate 3.3, c3p0, MySql 5.1 et Spring. Les connexions MySQL dans mes appels de service sont systématiquement fermées après ~ 39 minutes. Le temps de fonctionnement naturel de mon appel de service est de l'ordre de ~ 5 heures.La meilleure façon de déboguer les connexions MySQL qui sont fermées sur moi après ~ 39 minutes?

J'ai essayé de changer diverses configurations de c3p0, etc., pour éviter le chapeau de 39 minutes. Pas de chance.

Existe-t-il un moyen plus direct et systématique de consigner ou de résoudre ce problème? c'est-à-dire que je peux savoir pourquoi la connexion est fermée, et par , à quelle couche?

Mise à jour: pile trace

24 Oct 2010 02:22:12,262 [WARN] 012e323c-df4b-11df-89ed-97e9a9c1ac19 (Foobar Endpoint : 3) org.hibernate.util.JDBCExceptionReporter: SQL Error: 0, SQLState: 08003 
24 Oct 2010 02:22:12,264 [ERROR] 012e323c-df4b-11df-89ed-97e9a9c1ac19 (Foobar Endpoint : 3) org.hibernate.util.JDBCExceptionReporter: No operations allowed after connection closed. 
24 Oct 2010 02:22:12,266 [ERROR] 012e323c-df4b-11df-89ed-97e9a9c1ac19 (Foobar Endpoint : 3) org.hibernate.event.def.AbstractFlushingEventListener: Could not synchronize database state with session

Source

2010-10-24 Aaron Fi

+0

Regardez ceci: http://www.databasesandlife.com/automatic-reconnect-from-hibernate-to-mysql/ –

+0

Avez-vous une stacktrace? Si oui, ajoutez-le à la question. –

+0

Stacktrace ajouté. –

Répondre

1

Je veille prolongée 3.3, C3P0, MySql 5.1, et au printemps. Les connexions MySQL dans mes appels de service sont systématiquement fermées après ~ 39 minutes. Le temps de fonctionnement naturel de mon appel de service est de l'ordre de ~ 5 heures.

Je ne suis pas sûr d'avoir compris. Avez-vous des processus qui sont supposés fonctionner pendant 5 heures mais qui sont actuellement interrompus après ~ 39mn (ou probablement 2400 secondes). Pouvez-vous confirmer? Qu'est-ce qui marche déjà? Avez-vous changé quelque chose?

En attendant, voici quelques idées:

  • départ avec la base de données (voir B.5.2.11. Communication Errors and Aborted Connections)
    • démarrer le serveur avec l'option --log-warnings et vérifiez les journaux pour les messages suspects
    • voir si vous pouvez reproduire le problème en utilisant un client MySQL de l'hôte db
    • si cela fonctionne, faites la même chose à partir de la machine du serveur d'applications
    • si les travaux, vous saurez MySQL est ok
  • mouvement au niveau du serveur d'applications
    • activer l'enregistrement (de mise en veille prolongée et C3P0) pour obtenir une trace de pile complète et/ou plus des conseils sur les le coupable
    • aussi s'il vous plaît montrer vos paramètres de configuration C3P0

Et ne pas oublier que la configuration de C3P0 lorsque nous Hibernate est very specific et certains paramètres doivent aller dans un fichier c3p0.properties.

Source

2010-10-24 22:33:03

+0

Mon processus est un traitement par lots pour une grande charge de travail. J'ai artificiellement limité la charge de travail - elle se termine dans les 10 minutes. Lorsque j'augmente la taille de la charge de travail, les connexions fermées se traduisent par ~ 34 à ~ 39 minutes. –

+0

Le journal de requête MySQL confirme que la connexion est terminée par le client et non par MySQL lui-même. Le client initie une annulation, puis ouvre une nouvelle connexion (différente). –

+0

@Aaron Ok, c'est une première étape intéressante dans le diagnostic. Avez-vous un stacktrace utile (une stacktrace complète) côté client? Pourquoi annule-t-il la transaction? –

 Questions connexes

  • Aucun problème connexe^_^