Historiquement, le Wrapper a toujours utilisé l'heure système pour la mesure interne du temps. Dans la majorité des cas, cela fonctionne parfaitement. Cependant, il existe quelques cas où cela échouera ou où le Wrapper ne fera pas ce qui pourrait être attendu :

• Si le Wrapper se trouve dans une situation où il concurrence le CPU avec d'autres processus fonctionnant à une priorité plus élevée, il est possible que le Wrapper et/ou sa JVM ne reçoivent aucun cycle CPU pendant de longues périodes. Le Wrapper a toujours géré ces cas en utilisant une logique qui détecte de telles situations et prolonge de manière appropriée les délais d'attente concernés. Dans de rares cas cependant, le Wrapper pensera à tort que la JVM est figée et la redémarrera.

• Changements de l'heure système. Si l'heure système est avancée ou reculée de plus de quelques secondes pendant que le Wrapper est en cours d'exécution, un ou plusieurs de ses délais d'attente pourraient être déclenchés, entraînant un redémarrage involontaire de la JVM. Dans la plupart des cas, le Wrapper gérera les changements d'heure comme si le processus avait manqué de CPU. Mais il existe des cas où cela échouera.

  En général, avancer l'horloge système fonctionne correctement. Un message s'affichera dans la console pour informer l'utilisateur que le Wrapper n'a reçu aucun CPU pendant x secondes. Mais le Wrapper continuera de fonctionner correctement.

  En revanche, reculer l'heure système peut provoquer un certain nombre de problèmes selon l'état exact du Wrapper au moment où cela se produit. En interne, le Wrapper planifie des événements à des moments futurs spécifiques où des opérations comme le ping, ou le lancement d'une nouvelle JVM, doivent avoir lieu. Si l'heure est reculée d'une heure, alors une opération qui devait avoir lieu après 5 secondes n'aura lieu que dans une heure et 5 secondes. Si le timing est parfait, le Wrapper peut cesser d'envoyer des pings à la JVM et la JVM réagira à l'absence de pings en initiant un redémarrage de la JVM.

  NOTE

  Heure d'été

  Le Wrapper ne fonctionnera pas correctement pendant le changement d'heure d'été. Si vous vivez dans un pays qui aime changer l'heure chaque printemps et chaque automne, il est alors recommandé d'utiliser le minuteur à ticks pour éviter les délais d'attente.

  Comme décrit ci-dessus, vous pourriez obtenir un seul redémarrage de la JVM au printemps ou en automne lorsque l'heure système est ajustée. Une fois la JVM redémarrée cependant, votre application devrait continuer à fonctionner correctement.

• Mise en veille et reprise du système. Si le Wrapper est utilisé sur un système pouvant être mis en veille sur disque ou en RAM pendant de longues périodes, l'heure système semblera avoir sauté en avant lorsque la machine est reprise. Hormis un message dans la console, cela fonctionne correctement.

À partir de la version 3.1.0 du Wrapper, un nouveau mécanisme de minuterie a été ajouté au Wrapper. Cette nouvelle minuterie est devenue la valeur par défaut dans la version 3.2.0 du Wrapper. Plutôt que de mesurer le temps en interrogeant l'horloge système, le Wrapper crée un thread en arrière-plan qui entre dans une boucle légère et incrémente un compteur interne de « ticks ». En interne, toute la mesure du temps a été modifiée pour se baser sur ces « ticks ». (Si l'heure système est utilisée, alors le nombre de ticks à un moment donné est calculé à partir de l'heure système plutôt qu'à partir du compteur.)

Cela s'est avéré présenter un certain nombre d'avantages :

• Le Wrapper n'est plus affecté par les changements de l'heure système, que ce soit en avant ou en arrière. Cela garantit que le Wrapper se comportera correctement chaque fois que l'heure système est ajustée pour l'heure d'été ou d'autres ajustements.

• Lorsqu'un système mis en veille est repris, le Wrapper continue là où il s'était arrêté sans aucun problème.

• Le Wrapper gère de manière fiable les cas où il s'exécute dans un état de manque de CPU car le compteur de ticks est incrémenté à un rythme qui reflète la quantité de CPU reçue, plutôt que d'être absolu. Cela signifie que les délais d'attente dus à des charges élevées sont très peu probables.

  Dans des cas extrêmes, si le Wrapper reçoit un peu de CPU mais que la JVM est complètement privée de CPU, ou vice versa, des délais d'attente seront toujours possibles. Les deux processus fonctionnent toutefois toujours exactement à la même priorité, donc cela est très peu probable.

Il existe cependant quelques inconvénients à utiliser un compteur de « ticks » pour la mesure du temps :

• Le minuteur à ticks nécessite qu'un thread supplémentaire soit alloué au sein du Wrapper natif. Cela entraîne une légère augmentation des ressources nécessaires pour exécuter le Wrapper.

  Le côté Java du Wrapper utilise un thread qui était déjà utilisé pour vérifier les signaux système, il n'y a donc pas d'augmentation des ressources du côté Java.

• À toute charge CPU inférieure à 100 %, les threads de minuterie recevront toujours juste assez de CPU pour incrémenter leurs compteurs et rester temporellement précis. Mais lorsque le système fonctionne à 100 % de CPU, le thread ne pourra pas boucler à pleine vitesse, ce qui entraînera une incrémentation plus lente du compteur. Dans la plupart des cas, c'est en réalité une bonne chose. Cependant, cela rendra parfois incohérentes des opérations comme l'intervalle de ping, il faut donc garder ce fait à l'esprit.

Compatibilité :	3.1.0
Éditions :
Plateformes :

La propriété wrapper.timer_slow_threshold affichera un message dans le journal chaque fois que le minuteur à « ticks » prend du retard sur l'heure système de plus d'un nombre de secondes seuil, au cours d'une seule boucle du thread de minuterie. La valeur par défaut de cette propriété est très élevée afin de la désactiver effectivement.

wrapper.timer_slow_threshold=10

Définir le seuil lent à une valeur basse comme 1 seconde fournira des informations utiles sur les moments de la journée où le système est sous charge.

Une valeur de « 0 » (zéro) affichera chaque moindre glissement temporel et n'est en général pas très utile. Même sous une charge très légère, le minuteur prendra légèrement du retard sur l'horloge système simplement parce que la boucle elle-même prend un temps fini pour se terminer.

Des valeurs légèrement plus élevées comme 10 secondes peuvent en réalité être assez utiles car elles indiqueront les périodes majeures de charge élevée sur le système, sans s'encombrer de consigner chaque petit à-coup du CPU.

Tout ajustement de l'horloge système vers l'avant sera interprété comme une période de charge CPU élevée ayant duré le temps pendant lequel l'horloge a été avancée.

Si par exemple vous avez défini cette propriété à une valeur basse et que l'horloge système est soit avancée d'une minute, soit sous une charge extrêmement lourde pendant une minute, vous verrez dans vos journaux une sortie comme la suivante :

INFO   | wrapper  | 2004/07/21 08:52:01 | The timer fell behind the system clock by 60000ms.
INFO   | jvm 1    | 2004/07/21 08:52:15 | The timer fell behind the system clock by 60000ms.

La paire de messages indique que les processus Wrapper et JVM ont tous deux remarqué le changement d'heure système. Il est assez courant que les nombres rapportés par les deux processus diffèrent légèrement lorsque cela est dû à une charge élevée.

Compatibilité :	3.1.0
Éditions :
Plateformes :

La propriété wrapper.timer_fast_threshold affichera un message dans le journal chaque fois que l'heure système prend du retard sur le minuteur à « ticks » de plus d'un nombre de secondes seuil, au cours d'une seule boucle du thread de minuterie. La valeur par défaut de cette propriété est très élevée afin de la désactiver effectivement.

wrapper.timer_fast_threshold=0

Définir le seuil rapide à une valeur basse n'est généralement pas aussi utile que la propriété de seuil lent ci-dessus. En fonctionnement normal, le minuteur à « ticks » n'avancera jamais au-delà de l'heure système. La seule exception est le cas où l'horloge système a été reculée. Définir la valeur de la propriété à « 0 » (zéro) détectera tout ajustement de ce type de l'horloge système vers l'arrière.

Si par exemple vous avez défini cette propriété à une valeur basse et que l'horloge système est reculée d'une minute, vous verrez dans vos journaux une sortie comme la suivante :

INFO   | wrapper  | 2004/07/21 08:52:01 | The system clock fell behind the timer by 60000ms.
INFO   | jvm 1    | 2004/07/21 08:52:15 | The system clock fell behind the timer by 60000ms.

La paire de messages indique que les processus Wrapper et JVM ont tous deux remarqué le changement d'heure système.