web-dev-qa-db-fra.com

Avertissement de journal: famine de fil ou saut d'horloge détecté (delta housekeeper = springHikariConnectionPool)

J'utilise HikariCP 2.4.6 et au démarrage de Tomcat 8, je reçois un message d'avertissement:

01-Aug-2016 11:18:01.599 INFO [RMI TCP Connection(4)-127.0.0.1] org.Apache.catalina.core.ApplicationContext.log Initializing Spring FrameworkServlet 'Spring MVC Dispatcher Servlet'
[2016-08-01 11:18:01,654] Artifact blueberry:war exploded: Artifact is deployed successfully
[2016-08-01 11:18:01,655] Artifact blueberry:war exploded: Deploy took 33,985 milliseconds
Aug 01 2016 11:26:52.802 AM [DEV] (HikariPool.Java:614)
WARN : com.zaxxer.hikari.pool.HikariPool - 9m13s102ms - Thread starvation or clock leap detected (housekeeper delta=springHikariConnectionPool).

Je ne vois aucune autre erreur ou problème de lecture/écriture dans la base de données. Est-ce quelque chose à craindre? J'ai essayé de chercher autour, mais pas de chance.

Nous utilisons également Hibernate 4.3.8.Final sur MySQL 5 et le connecteur MySQL 5.1.39 avec Spring 4.1.0.RELEASE. Nous travaillons à la mise à niveau vers Hibernate 5 et verrons si cela disparaît, mais je ne sais pas si cela importera.

hikaricp
20
bphilipnyc

Je viens de remarquer qu'il existe une version légèrement plus récente de HikariCP ( 2.4.7 ) qui a résolu ce problème d'apparaître sur mon instance.

Il y a un bon récapitulatif des raisons pour lesquelles les détections de sauts d'horloge peuvent légitimement se produire. Pour citer le lien externe de Brett Woolridge:

Cela s'exécute sur le thread de femme de ménage, qui s'exécute toutes les 30 secondes. Si vous êtes sous Mac OS X, le clockSource est System.currentTimeMillis (), toute autre plate-forme le clockSource est System.nanoTime (). Les deux en théorie augmentent de façon monotone, mais diverses choses peuvent affecter cela, comme NTP serveurs. La plupart des systèmes d'exploitation sont conçus pour gérer en arrière NTP ajustements de temps pour préserver l'illusion) de l'écoulement du temps.

Ce code dit, si le temps recule (maintenant <précédent), ou si le temps a "sauté en avant" plus de deux périodes de ménage (plus de 60 secondes), alors quelque chose d'étrange se passe probablement.

Deux choses pourraient se produire:

  1. Vous pourriez être exécuté dans un conteneur virtuel (VMWare, AWS, etc.) qui, pour une raison quelconque, fait un travail particulièrement médiocre pour maintenir l'illusion du flux de temps en avant.

  2. Parce que d'autres choses se produisent dans le thread de femme de ménage - en particulier, la fermeture des connexions inactives - il est possible que, pour une raison quelconque, la fermeture des connexions bloque le thread de femme de ménage pendant plus de deux périodes de maintenance (60 secondes).

  3. Le serveur est tellement occupé, avec tous les processeurs arrimés, que la famine de thread se produit, ce qui empêche le thread de femme de ménage de s'exécuter pendant plus de deux périodes de maintenance.

Compte tenu de ces éléments, vous pouvez peut-être fournir un contexte supplémentaire.

EDIT: Notez que cela est basé sur le code HikariCP 2.4.1. Assurez-vous que vous utilisez la version la plus récente disponible.

(Il semble également que les paramètres ont été mis à jour sur la déclaration d'avertissement dans le dernier code.)

19
bphilipnyc