Das Notes Forum
Domino 9 und frühere Versionen => ND8: Entwicklung => Thema gestartet von: ghostmw am 03.05.11 - 14:04:10
-
... wir haben eine kleine Beispiel-Datenbank mit einer Ansicht und einem Agenten.
Der Dominoserver ist ein 8.5.2 bzw. 8.5.1 FP4 (dort ist es genauso).
Der Agent hat folgenden Scriptcode ...
Sub Initialize
Dim session As New NotesSession
Dim dbThis As NotesDatabase
Dim docThis As NotesDocument
Dim dblCount As Double
Set dbThis = session.CurrentDatabase
Set docThis = dbThis.CreateDocument
For dblCount = 1 To 100000
Call docThis.ReplaceItemValue ( "Count" ,dblCount )
Call docThis.Save ( True , False )
Next
Call docThis.Remove ( True )
End Sub
Soweit so gut ... das interessante ist nun, lässt man den Agenten laufen (per "tell amgr run "test.nsf" 'agStartTest'"), der das eine Dokumente 100.000 mal abspeichert und ein Feld hochzählt.
Dann ist das "Aktivität: geändert" auf dem 2. Reiter der DB-Eigenschaften in der Zukunft und je nach Agentenlauflänge auch verdammt weit.
Hat das jemand noch entdeckt ?
Das klingt so unglaublich ...
Das gleiche passiert, wenn ich Dokumente per Agent von einer DB auf dem Server nach lokal kopiere, dann sind die Daten dieser kopierten Dokumente und der lokalen DB auch in der Zukunft.
Auch das Neuanlegen von Dokumente in solch einer Schleife bringt das gleiche Ergebnis, die Zeit wandert in die Zukunft.
Wir werden das mal parallel mit der Beispiel-Datenbank an die IBM senden. Ich bin gespannt...
-
Kann ich nicht reproduzieren. Weder unter 8.5.2 PP2 noch unter 8.5.3 Beta 4
-
... komisch, bei uns klappts problemlos auf 2 Servern und die Zeiten sind in der Zukunft.
Wir haben noch kein PP2(?), sollte das nicht FP2 heißen?
Steht was in der Fixlist von FP1/FP2 was drin, was wir übersehen haben sollten?
-
Kann das hier mit dem geposteten Code mit 8.5.1FP3 direkt nachstellen. Agentenlaufzeit: 14 Sekunden, Zeit der Datenbank ist 50min in der Zukunft...
Ich mache mal ein Update auf 8.5.2FP2 und teste erneut..
Gruss
Tode
-
Unter VMWare?
-
Ist das nicht der berühmte Time Creep?
https://www-304.ibm.com/support/docview.wss?uid=swg21327441
-
... gute Idee.
Da war mal was mit Zeit verstellt und VMWare, aber das betraf alle Datenbanken und nicht nur eine, oder ?
Dagegen spricht die Tatsache, dass wir mit der DB lokal und einem lokalen Client das gleiche Problem haben.
Und da ist kein VMWare dazwischen.
-
habs grade auch nochmal mit einem Physischen Server 8.5.2FP1 probiert -> gleiches Problem...
Bin nun gerade am Update auf 8.5.2FP2 um weiter zu testen... VMWare können wir also ausschliessen...
Gruss
Tode
-
8.5.2FP2 -> Fehler immer noch vorhanden.
Ich fasse zusammen:
8.5.1FP3, Domäne1, VMWare -> Fehler
8.5.2FP1, Domäne2, Physischer Server -> Fehler
8.5.2FP2, Domäne1, VMWare -> Fehler
Jetzt könnte ich noch meinen DEV- Server auf 8.5.3 BETA updaten...
-
Test mit ODS 43 und ODS 51 -> Kein Unterschied...
-
Habe es gerade noch einmal getestet. Keine Ahnung, was vorher falsch / richtig gelaufen ist. Jetzt kann ich es nachstellen. Server ist Domino 853 CD4 (64Bit) auf Win2008R2 (64bit)
Laufzeit 10sec.
-
jupp, habe es gerade auch auf CD4 32 bit probiert -> gleicher Fehler...
Wow... fetter BUG !?
-
Habe es im Design Partner Forum gepostet. Mal sehen, was kommt.
-
... habe mittlerweile eine Serviceanforderung bei der IBM aufgemacht.
Anforderungsnummer 02131 070 724
-
OK, da können wir uns ja dann dranhängen. Danke
-
Ich kann das in diesen Tagen leider nicht selbst nachvollziehen, daher ein paar Fragen an die "Betroffenen":
Was passiert mit der Serverzeit an sich? Wir die dann periodisch wieder mit der OS-Zeit korrigiert?
Bekommen Dokumente anderer DBs auch "falsche" Zeitstempel?
Was passiert, wenn mit "falscher" Zeit zwischendurch repliziert wird?
Danke.
Bernhard
PS: "Falsch" in Anführungszeichen deshalb, weil aus Domino-Sicht die zeit ja "stimmt".
-
Bernhard: die Server / OS Zeit ändert sich nicht. Die ist korrekt. Es geht lediglich um den Last Modified TimeStamp der Datenbank.
Die Dokumente selber sind nicht betroffen, soweit ich das momentan sehe.
-
Die Serverzeit ändert sich nicht... man kriegt in der Serverkonsole weiter korrekte Zeitangaben. Daraus haben eknori und ich ja die Agentenlaufzeit von 10 Sekunden abgeleitet... Scheinbar haben wir ne Art "Timewarp" innerhalb der Agenten- Laufzeitumgebung, der sich aber nicht generell auf den Server auswirkt.
... eknori war schneller...
-
Danke, Ulrich und Torsten!
Bernhard
-
Bin gerade dabei zu testen, ob sich das irgendwie auf die replikation auswirkt.
Edit: kann keine Auswirkungen erkennen
-
IBM Reaktion
Forwarded to development.
-
... hab noch was dazu beizutragen.
Wir haben eine große Applikation bei der wir den RnRMgr-Task mit benutzen, indem wir einige Sache mit der Ressourcen-DB machen, die man so normalerweise nicht kann, wie z.B. Reservierungen mit Karenzzeiten versehen (auch wenn sie aus dem Kalender kommen), dazu ist es u.a. notwendig selbst Notices (NoticeType="U", RQStatus = "T") zu versenden.
Dabei ist uns die Zeitverschiebung das erste Mal aufgefallen ... dann haben wir das Beispiel s.o. konstruiert und siehe da es liegt nicht an unserem Code (puuuuh...).
Sollen in einer DB aus der "Zukunft" per RnRMgr-Task Reservierungen (mit Zukunftsdatum) verbucht werden, passiert nichts, wenn es sich um Aktualisierungen handelt (NoticeType = "U" und RQStatus = "T").
Es gibt auf alle Fälle durcheinander in der busytime.nsf bzw. clubusy.nsf und auch was schlussendlich verbucht wurde.
Danke auch von meiner Stelle an alle fürs Testen der versch. Versionen ... ;)
Neues von der IBM:
...
I work on the Application Development team in Lotus Support and I
received the details of this issue this afternoon. I am currently
investigating and will contact you again shortly with my initial
findings.
...
-
... noch was neues, den Cluster steckt das Modified-Datum in der Zukunft auch an.
Ich habe dieselbe Datenbank im Cluster vorliegen.
Starte auf dem einen Clustermember den Agenten, dessen Modified-Datum liegt in der Zukunft.
Durch die Clusterreplikation das Modified-Datum der Cluster-Datenbank auch, nicht ganz soviel aber auch mehrere Minuten bei 10.000 Dokumenten.
Das scheint wirklich ein größeres Problem zu sein ...
-
Hab das auf einem Server 6.0.2 auch mal laufen lassen. Gleiches Ergebnis, also kein Bug von 8.5.x, sondern schon älter
-
... es gibt was neues von IBM.
...
I have carried out further research into this issue and can confirm that the behaviour you are seeing has been reported previously in the following SPR (Software Problem Report):
SPR #DWHN85CCVH: Modified time of document created is set in the future by approximately 30 minutes.
The SPR describes an identical case, where an agent creating many document updates results in documents with a modified time in the future, with the same for the database modified time. This was investigated by Lotus Software Quality Engineering who determined this not to be a bug but the correct behaviour. This behaviour is necessary to ensure the correct functioning of replication, which requires a unique time for each change. The agent updates the document and saves it each time. Notes/Domino is designed to increase the time of a database when rapid document changes are made in order to preserve the uniqueness for replication. If you were to make the document save outside the loop so that it saves just once then you would not see this effect. For the code provided here the database will continue to mark documents modified in the future until there is no further document activity and the system time has time to catch up to the future time.
Another similar SPR describes the effect as follows:
After the real server time reaches the incorrect 'modify time' then 'creation time' and 'modify time' become the same and will match with the real server time.
...
... das ist genau das, was mir Kopfzerbrechen macht.
"Works as designed" ... aber wie verhält sich aber dabei der RnRMgr, die Replikation etc..
Ich werde das bei der IBM nochmals detailliert nachfragen und dann wieder informieren.
-
Also ist das ein Wert, der in der UI überhaupt nichts zu suchen hat, weil man damit eh nichts anfangen kann/soll und der nur für die systeminterne Verarbeitung gedacht ist.
-
... das könnte man meinen.
Die spannende Frage ist jetzt aber ... was passiert, wenn ich in meiner Reservierungs-DB z.B. bei allen Reservierungen ein neues Feld initial setze oder sonstige Änderungen vornehmen. Angenommen ich habe 10.000 Reservierungen.
Kommt dann der RnRMgr-Task durcheinander ? Ignoriert er ggf. Reservierungen, die mit der richtigen realen Zeit abgespeichert werden, weil das Datum für den Raum in der Zukunft ist ?
Ich werde es mal versuchen nachzubauen und die Ergebnisse posten.
In der Zwischenzeit habe ich die IBM mal drum gebeten eine Stellungnahme abzugeben, inwieweit die einwandfreie Funktion der Systemtasks wie Replicator, RnRMgr oder AMgr beinträchtigt sind.
-
Das ist doch völlig normal. Das passiert in jedem replizierenden System gleich.
Du änderst 100.000 mal das selbe Dokument. Domino muß für jeden dieser Schreibzugriffe die Änderungszeit erhöhen. Wenn nun die Schreibzugriffe schneller erfolgen als die Auflösung des Zeitfelds ist, muß er die Zeit künstlich erhöhen.
Gehen wir der Einfachheit davon aus, dass das Zeitfeld der letzten Änderung eine Auflösung von Millisekunden hat. und 10 Schreibzugriffe pro Millisekunde erfolgen. Dann wechselt die Uhrzeit nur bei jedem 10 Schreibzugriff. Damit Domino aber für die Replizierung aber den Schreibzugriff erkennt muß er die Zeit künstlich um eine Millisekunde erhöhen. Wie gesagt nur ein Beispiel, habe keine Ahnung wie groß die Auflösung eine Zeitfelds in Domino ist. Könnte man aber mit Tools problemlos herausfinden.
In der Praxis wird dieses Problem kaum auftreten, da ein so oftes Schreiben des Dokuments sehr schlechter Programmierstil ist.
Grüße
Ralf
-
... spannend wirds aber, wenn z.B. der RnRMgr sich an einem Dokument die Zähne ausbeißt, und es aufgrund der erneuten Speicherung immer und immer wieder abspeichert in einer Endlosschleife, das hatten wir auch schon mal.
Ich bin grade aktuell mit der IBM noch dran herauszufinden, was im Zusammenhang mit Reservierungen aus dem Kalender und der Reservierungs-DB in der "Zukunft" passiert.
Ich meine, dass Raumreservierungen und Updates aus dem Kalender heraus nicht vom RnRMgr verarbeitet wurden.
-
Moin,
wollte mich nochmals kurz rückmelden in der Sache.
Ich habe in einer Standardreservierungs-Datenbank nun mal versucht den RnRMgr aus dem Gleichgewicht zu bekommen.
Also zuerst täglich einen Kalendereintrag per Agent erstellen lassen, insgesamt 25.000 Stück.
Damit ist die Datenbank ein paar Stunden in der Zukunft.
Und dann habe ich alles Mögliche versucht:
- Besprechung aus dem Kalender heraus mit Raum gebucht. => wurde sauber verbucht
- Besprechung aus dem Kalender heraus mit Raum geändert. => wurde sauber verbucht
- in bestehender Besprechung aus dem Kalender heraus Raum dazu gebucht. => wurde sauber verbucht
- in bestehender Besprechung aus dem Kalender heraus Raum entfernt. => wurde sauber verbucht
- Eintrag direkt in der Reservierungs-DB erstellt. => wurde sauber verbucht
- Eintrag direkt in der Reservierungs-DB geändert. => wurde sauber verbucht
- Eintrag direkt in der Reservierungs-DB Raum geändert. => wurde sauber verbucht
- Eintrag direkt in der Reservierungs-DB Zeit geändert. => wurde sauber verbucht
Scheint also alles zu funktionieren, trotz Modified-Datum in der Zukunft.
Hmmm... aber irgendwie habe ich ein komisches Gefühl bei der Sache.
P.S.: Von der IBM habe ich nichts mehr gehört, obwohl ich per Mail darum bat, daß ich ein Statement zum Verhalten des RnRMgr haben wollte, schade.
-
Vielen Dank erst einmnal für die Mühe, die du dir gemacht hast. Das ist mit Sicherheit wertvolles Wissen, das man sich verlinken sollte.
P.S.: Von der IBM habe ich nichts mehr gehört, obwohl ich per Mail darum bat, daß ich ein Statement zum Verhalten des RnRMgr haben wollte, schade.
Hattest du etwas anderes erwartet? Ich nicht. Für die IBM sind solche Dinge absolut nebensächlich. Das Verhalten gibt es offenbar schon seit Jahren ( works as designed ) und es hat auch offensichtlich immer funktioniert. Zumindest ist niemandem irgend etwas negativ aufgefallen. Und wenn dann irgendwann einmal wirklich ein Problem auftauchen sollte, ist immer noch Zeit, sich damit zu beschäftigen. Damit ist das Thema vom Tisch.