Wie NTP-Server bei der Planung von Aufgaben in Java-App verwenden?

Question

Ich weiß, dass NTP-Server verwendet werden können, um die Systemuhr Ihres Computers zu synchronisieren. Aber kann NTP von einer Anwendung verwendet werden, die Dinge mit anderen Systemen synchronisieren möchte?

Szenario: Entwickeln einer Java-App (vielleicht in einem ESB wie Mule laufen) und Sie werden nicht unbedingt in der Lage sein, die Zeit des Computers zu steuern, auf dem es ausgeführt wird. Kann Ihre App einen NTP-Server verwenden, um die Zeit zu erhalten und geplante Aufgaben zu dieser Zeit auszuführen?

Nehmen wir an, Sie verwenden Quartz als Scheduler und vielleicht Joda-Zeit für die Handhabung Zeiten (wenn das nützlich ist). Die Zeit muss nicht sehr präzise sein, nur um Fernsystemen weit voraus zu sein.

Answer 1

Aber kann NTP von einer Anwendung verwendet werden, die Dinge mit anderen Systemen synchronisieren möchte?

Ich habe noch nie davon gehört, dass es so verwendet wird. Nichts dagegen hält Sie davon ab, einen Client für das Network Time Protocol (RFC 1305) zu implementieren. Eine vollständige NTP-Implementierung ist wahrscheinlich übertrieben, aber Sie können das Protokoll auch im SNTP-Modus (RFC 2030) verwenden.

Wahrscheinlich möchten Sie einen lokalen NTP-Server einrichten und verwenden, wenn Sie hohe Verfügbarkeit und angemessene Genauigkeit wünschen.

Eine Google-Suche zeigt, dass es eine Reihe von Java NTP-Clients sind da draußen ...

Answer 2

Meine Intuition sagt mir, dass die NTP eine Hardware-Uhr Anpassungen erfordert einen Schritt zu halten. Wenn Sie also keinen Zugriff auf die Hardware haben, können Sie das nicht tun.

Wenn es jedoch ausreicht, ein paar Sekunden Genauigkeit zu haben, könnten Sie regelmäßig Sample-Zeit von einem Server senden, um einen Versatz zwischen der Systemuhr und der geplanten Zeit für Jobs zu berechnen.

Answer 3

Wenn Sie nicht sehr besorgt über Drift sind, und davon ausgehen, dass die Maschinen nicht nur die Zeit zufällig ändern, dann könnten Sie einen NTP-Server anpingen, um zu sehen, wie viel Zeit die IT denkt und vergleichen Sie das mit der Zeit lokale Maschine denkt, dass es ist, dann berechnen Sie das Differential und schließlich planen Sie Ihre Aufgabe in Ortszeit.

So sagen Sie zum Beispiel, dass der NTP-Server sagt, dass es 12:30 ist, aber Ihr lokaler Computer sagt, dass es 12:25 ist. Und Sie möchten, dass Ihre Aufgabe um 13:00 Uhr NTP-Zeit abläuft.

So, 12:25 - 12:30 = -0: 05. 13:00 + (-0: 05) = 12:55, deshalb planst du deine Aufgabe für 12:55.

Addenda -

ich auf die Naivität einer Implementierung kann nicht sprechen, ich bin nicht vertraut genug mit dem Protokoll.

Am Ende kommt es darauf an, welches Maß an praktischer Genauigkeit für Sie akzeptabel ist. NTP wird verwendet, um die Zeit zwischen Systemen zu synchronisieren. Eines der Probleme, die es löst, besteht darin, ständig aufgerufen zu werden, es verhindert das Kriechen der Uhr. Wenn Sie die "NTP Ping, planen mit Offset" -Technik verwenden, und sagen, dass zukünftige Zeit vielleicht 8 Stunden in der Zukunft ist, gibt es eine sehr reale Möglichkeit des Uhrkriechens, das heißt, obwohl Sie wollten, dass die Aufgabe bei " 12:55 ", wenn 12:55 herumläuft, könnte es vom ursprünglichen NTP-Server abweichen, da die Uhren nicht synchronisiert wurden (und überhaupt nicht), und der Job wurde nicht auf eine virtuelle Neusynchronisierung umgestellt.

Je länger der Zeitraum zwischen dem ursprünglichen Zeitplan und der tatsächlichen Ausführung ist, desto größer ist das Potenzial für die Drift. Dies ist ein Artefakt, egal wie gut der ursprüngliche NTP-Ping ist. Wenn Sie nicht planen, diese Aufgaben neu zu planen, da sie der Ausführungszeit nahe kommen, um die Abweichung auszugleichen, dann sind die Chancen einer "vernünftigen" Implementierung von NTP angemessen.

Es gibt die Apache Commons NET-Bibliothek, die einen NTP-Client hat. Einige beschweren sich, dass es System.currentTimeMillis() verwendet, das unter Windows Probleme mit der Auflösung (10-15ms) hatte. System.nanoTime behebt dies, und Sie können die Bibliothek leicht ändern, um sie zu verwenden und sie neu zu erstellen.

Ich kann nicht sprechen, wie es die "Naivität" der Implementierung widerspiegelt. Aber am Ende kommt es darauf an, wie nahe es ist, die beiden Maschinen und ihre Jobs (virtuell) synchron zu halten.