Quartz Scheduller , kurzes Intervall > grosse Differenz, ist das "Normal"?

Nobody

Mitglied
Hi...

Grosses Problem kurz geschildert:

Ich benutze für ein Client-Server bassiertes MMO,
Serverseitig den im Backend-Server (red5) Implentierten Quartz scheduller.

Dieser liefert mir dan einen Pool von 10 Job-Workern welche sich bei der Abarbeitung der Jobs der reihe nach Abwechseln.

Ich brauche für dieses Zeitintervall Werte von 150 MilliSekunden erhalte jedoch ZeitIntervalle von 96-203 MilliSekunden (dazwischen ist alles dabei z.B.121,143,172...ms.). Zuweilen lese ich auch Unterschiede von "nur" 78ms oder gar 348 ms, was aber äusserst selten passiert.

Mir ist aufgefallen das die Werte der Worker immer annähhernd 10 multipliziert dem Wert des Zeitintervalls ist, somit auch in jeder "Sequenz" beispielsweise worker 8 zu worker 9 eine annährend immer gleichen unterschied hat also meinetwegen sich immer jeweils um die 170 ms bewegt.

Nun zur eigentlichen Frage:
Ist das ein "übliches, normales" verhalten des Quartz Schedullers oder liegt das "vermutlich" an der Implementierung im Server?

Grundlage fürs eigentliche Problem, falls es interessiert...:
Da ich die Werte während dieser 150 ms Clientseitig Interpoliere und auch darauf angewiesen bin keine all zu grosse Latenz aufkommen zu lassen ist das aktuelle Ergebniss recht Unbefriedigend, man sieht deutliche beschleunigungen so das es nicht flüssig läuft, meine Aktuell letzte hoffnung ist entweder ein Timer der genaue Intervalle hinbekommt oder ein Buffer für Mittelwerte welcher aber auch die Latenz erheblich steigert:).

bin für jeden ratschlag dankbar:)
 
hmm in der documentation steht das man auch millisekunden genau arbeiten kann...

Die Priorität der threads ist auf 5 gesetzt und es befinden sch 12 worker im SimpleThreadPool (nicht 10) allerdings glaub ich kaum das der job-thread auch nur annähernd 10 ms läuft...

Ich habe nun auf der red5 mailing.list gepostet, im quartz forum, in der opensymphony jira und in 2 Java Foren, Google spuckt bei der suche nach "java genauigkeit timer" zwar hinweise auf diverse RealTime VM´s welche aber wohl (was auch nicht genau beschrieben ist) wohl für nanosekunden bereiche zuständig wären... auch den red5 sourcecode hab ich schon durch und finde keine hinweise auf fehlerhafe implementierung, lediglich die thread priorität von 5 gibt mir zu denken, da die thread-laufzeit aber nie ausgeschöpft werden dürfte (zumindest unter aktuellen testbedingungen (2 user)) ist das auch ziemlich weit her geholt.

eines muss mal gesagt werden, unter java laufen eindeutig die innovativsten ideen, und java hat mit abstand die besten tools um documentationen automatisiert zu erstellen und wohlgeformten gut kommentierten source zu bauen, leider ist unter java sowohl der support oben besagter projecte als auch praxisbezogene beispiele mit abstand am schlechtesten vertreten.

wäre irgendwie echt toll... falls mir wenigstens einer sagen kann ob diese abweichungen "normal" sind und sich ein weitersuchen nicht lohnt...
 
Zuletzt bearbeitet:
Zurück