Beiträge von Akane

  • FTSearch: "FIELD PLZ=10000" ergibt "Abfrage ist nicht verständlich

    Hallo und einen schönen Restsonntag miteinander,



    Zitat


    So weit ich weiß kannst du ZAHLEN in einen FTI nur dann suchen wenn diesen explizit in der ft search aufgenommen sind. Kann es sein das den PLZ zufällig in dieses gefundene dokument auch als TEXT vorhanden ist, und nicht nur als Zahl ?


    Das mit PLZ=9999 gefundene Dokument hat definitiv den Datentyp "Zahl - 8 Byte". Die anderen Dokumente des Forms sind ebenfalls typentreu.


    Um was es mir bei der Frage geht:


    FTSearch() "weiß" offensichtlich bei der Query-Option "FIELD PLZ=9999", dass es sich bei PLZ um eine Zahl handeln muß.


    Denn ein


    FIELD PLZ="9999"


    anstelle von


    FIELD PLZ=9999


    führt ebenfalls zu einer unverständlichen Query.


    Bei der exponentialdarstellung von PLZ=1e5 wird offensichtlich versucht, eine scientific-notation von 10000 in den Dokumenten zu finden - was das leere Resultset erklärt.


    Kann es somit sein, dass es eine Beschränkung vom FTSearch-FIELD X=[0-9].* auf 4 Stellen gibt?
    Ist das dokumentiert oder sollte man vielleicht einen SPR aufmachen?


    Denn bei negativen Zahlen gab es immerhin auch schon mal ein Problem:


    http://www-1.ibm.com/support/docview.wss?&uid=swg21144490



    Zitat


    Persönlich würde ich solche zahlen IMMER zusätzlich als text hinterlegen, und dann mittels [PLZTXT]="10000" suchen, und nicht mit FIELD PLZ=10000


    Das Verändern von bestehenden Datenbanken ist immer so eine Sache - insbesondere wenn es proprietäre, zugekaufte Lösungen sind. Denn das Problem kuckte aus seinem Loch als es darum ging eine Datenbank via einem DAO zu integrieren.


    Trotzdem vielen Dank



    a--

  • FTSearch: "FIELD PLZ=10000" ergibt "Abfrage ist nicht verständlich

    Hallo miteinander,



    gestern gab es ein ulkiges Phänomen beim FTSearch:


    Ein:


    View.FTSearch("FIELD PLZ=9999")


    funktioniert. Bringt auch ein existierendes Resultset.



    Ein:


    View.FTSearch("FIELD PLZ=10000")


    bringt "Abfrage ist unverständlich".


    Ein:


    View.FTSearch("FIELD PLZ=1e5")


    bringt zwar keine Fehlermeldung, aber auch kein Resultset, obwohl die Datenbank ein Dokument mit "10000" in dem numerischen Feld PLZ enthält und die View das auch darstellt.


    Wo hebt's denn da bitte?


    a--

  • Lausige Performance von Multithreaded Java-Agenten.

    Zitat


    Update: 16:14 Uhr:
    Soeben hat's den Server gerissen. Der Agent tut nichts mehr, "sh tasks" zeigt ihn noch an und "tell amgr cancel" jammert, daß der Agent nicht laufen würde.
    Ein "quit" auf der Konsole hängt und es riecht verstärkt nach NSD-Logs, die gerade erzeugt werden. So wird das nix.[...]


    Falls mal noch einer von so einem Servercrash gebissen werden sollte:


    Es handelt sich hierbei um das leidige FUTEX_WAIT unter der NPTL, welches insbesondere Java 1.4.2 betrifft.


    Läßt man den Server mit


    export LD_ASSUME_KERNEL=2.4.21


    laufen, laufen die Java-Agenten auf dem Domino-Server sauber durch und crashen nicht.


    Die Auswirkung auf die Performance ist hier zumindest mit den Java-Agenten nicht wirklich gut meßbar, die mir vorliegenden Meßergebnisse mit abgeschalteter NPTL zwischen 61 und 123 Dokumenten pro Sekunde schwanken. Ein zufällig während dem Agenten anlaufender UPDATE könnte einen durchaus höheren Einfluß auf die Zahlen haben, als die NPTL.


    Wie groß ist die zu erwartende Performance-Einbuße auf den Clients durch diese Maßnahme? Hat jemand vielleicht einen Link zu einer Performance-Messung die etwas genauer als die Angabe "huge impact" ;) ist ?


    a--

  • Lausige Performance von Multithreaded Java-Agenten.

    Gerade getestet:


    Zitat


    16.02.2007 03:42:07 PM AMgr: Agent '(juko_ohne_bb3_threaded) juko_ohne_bb3_threaded' is scheduled to run next at: 16.02.2007 03:45:00 PM
    16.02.2007 03:42:07 PM AMgr: Agent '(jskoeng_in_bb3_threaded) jskoeng_in_bb3_threaded' is scheduled to run next at: 16.02.2007 03:45:00 PM



    Das ist ja lustig! Der startet ja wirklich nur einen Agenten!


    Auch nicht schlimm - das lösen wir halt eben durch einen Cronjob, der mehrere "tell amgr run" an den Server schickt.


    Zitat


    Agent Manager Executive '3': Idle
    Agent Manager Executive '1': Running agent '(juko_ohne_bb3_threaded)|juko_ohne_bb3_threaded'
    Agent Manager Executive '2': Idle


    Aber wieder zurück zum Thema: Das eine sind - nicht näher zu kommentierende - Beschränkungen des Schedulers und das andere - die lausige Performance - ist eine Beschränkung der C-Api - und wie wir nun definitiv wissen - des Clients.


    Der Server ist - wie schon gesagt - ein Dual P3 1Ghz mit Linux - der Client das gute Windows XP auf einem Dual-Opteron 2,2Ghz. Und die Performance des Agenten auf dem Client ist - wohlwollend ausgedrückt - unterdurchschnittlich - auf dem Server geht das gerade mal so an.


    Hat noch irgendwer irgendwelche Einfälle, was man dem Client noch beibiegen kann, damit das wenigstens so schnell läuft, wie auf dem Server?


    Doch noch einen PMR aufmachen? :hammer:


    Update: 16:14 Uhr:
    Soeben hat's den Server gerissen. Der Agent tut nichts mehr, "sh tasks" zeigt ihn noch an und "tell amgr cancel" jammert, daß der Agent nicht laufen würde.
    Ein "quit" auf der Konsole hängt und es riecht verstärkt nach NSD-Logs, die gerade erzeugt werden. So wird das nix. Ich muß doch noch mal die Kundennummer von uns herauskramen und bei IBM jemandem das Wochenende versauen. Trotzdem Danke für die Bemühungen.


    a--

  • Lausige Performance von Multithreaded Java-Agenten.

    Nur der Vollständigkeit halber: Auf dem Server (Dual P3 1Ghz mit 4GB RAM) sieht die Anzahl der Dokumente pro Sekunde schon viel erfrischender aus. Einige Threads sind schon mir ihrer Teilmenge von 2000 Dokumenten durch - die anderen laufen noch:



    Jetzt fehlt nur noch der Geschwindigkeitsfaktor 3 und ich bin schon fast zufrieden. :)



    a--

  • Lausige Performance von Multithreaded Java-Agenten.

    Probier's doch mal aus und nimm zwei Agenten, die irgend etwas ins Notes-Log schreiben:


    tell amgr run "database.nsf" 'agent1'
    tell amgr run "database.nsf" 'agent2'


    Und schau' Dir das Notes-Log an.


    Hier auf dem Testserver printen gerade zwei unterschiedliche Agenten ihre Status in das Log. Der eine bearbeitet die Dokumentenklasse UKO und der andere die Dokumentenklasse SKO:


    Zitat

    16.02.2007 02:58:14 PM Agent Manager: Agent error: 2007-02-16 02:58:15.333 INFO1 : THREAD Nr 7 UKO in BB3 fertig - Dauer: 546.947


    16.02.2007 02:58:16 PM 0 Transactions/Minute, 8 Notes Users
    > 16.02.2007 02:58:18 PM Agent Manager: Agent error: 2007-02-16 02:58:19.799 INFO1 : THREAD Nr 9 UKO in BB3 fertig - Dauer: 547.662
    16.02.2007 02:58:20 PM Agent Manager: Agent printing: 2007-02-16 02:58:21.207 sko_in_BB3 : 2500 von 31874 Dokumenten ( 29374 fehlen ETA : 1,95 h ) 0 saved 2500 not saved


    Beide Agenten laufen in der selben Datenbank auf dem selben Server. Ich schwör's :)


    Mag sein, daß das in einer Pre-R7 nicht funktionierte. Was in R7 auch noch nicht funktioniert, ist die Anzeige der Transactions/Minute, wenn Serveragenten laufen. Die wurden in R5 auch schon nicht angezeigt.


    In R5 zumindest führte das Starten von Java-Agenten die mit JDBC an einer Postgres-DB Abgleiche fahren, zuverlässig zu einem Crash des Servers. Äh - wir reden doch noch von Java-Agenten?


    Und von der Julie habe ich auch schon lange nichts mehr gelesen. Ist die überhaupt noch bei dem Verein?



    a--

  • Lausige Performance von Multithreaded Java-Agenten.

    Zitat


    Es gibt ja die Einschränkung, daß innerhalb einer Datenbank auch immer nur ein Agent zur gleichen Zeit laufen kann.


    Seit wann denn das? Mir ist nur bekannt, daß man die Anzahl der gleichzeitig laufenden Agenten und deren Laufzeit beschränken kann. Aber das bezieht sich auch mehr auf das Serverdokument und nicht auf den Client.


    Wir haben durchaus mehrere Agenten gleichzeitig auf der gleichen Datenbank und auch auf dem gleichen Server laufen. Ansonsten hätten wir auch ein kleines Zeitproblem, wenn das der Fall wäre.


    Zitat


    Vermutlich wird dies bei den Threads genauso sein. Denn das Beispiel von Andrew Pollack greift ja auf zwei unterschiedliche Datenbanken laut Beschreibung zu.


    ... und läuft genauso in einen Synchronize der C-API wie hier. Seine Feststellung zumindest im Bereich der nichts weiter berechnenden Collection-Zugriffe ist noch graviender:


    Zitat


    Maybe even more interesting, is that while there was virtually no difference when doing this on one thread at a time -- in fact it was faster IN TOTAL to do it sequentially than on distinct threads.


    Aber diese Aussage kann ich hier gottseidank auch nicht nachvollziehen.


    Multithreading bringt zumindest an den Stellen einen Vorteil in der Größenordnung von knapp 100%, wenn man Berechnungen in den Agenten drin hat, die nicht auf die Notes-Daten zugreifen müssen. Wowereit! :)


    Denn die Zugriffe auf Notes-Daten besitzen offenbar ein in der API hart kodiertes Limit der gleichzeitigen Zugriffe, das auch schon in R5 vorhanden war und das auch noch in R7 vorhanden sein muß und das auch wohl nicht so einfach zu beseitigen ist, denn sonst wäre dies mit Sicherheit schon geschehen.


    Hat irgendwer mal zu dem Thema einen PMR eröffnet und mag die Aussage von IBM hier mal posten?


    a--


    P.S.: In Notes-Script lief der Agent damals 6 Stunden. In Java Singlethreaded zwei Stunden und mit Multithreading eine Stunde. Erwartet wären maximal 10 Minuten. Aber das wird sich offenbar zumindest mit R7 nicht darstellen lassen.

  • Lausige Performance von Multithreaded Java-Agenten.

    Nur noch der Vollständigkeit halber:


    Eine Session die von allen Threads verwendet wird, bringt hier bei dem Agenten nicht den massiven Geschwindigkeitsvorteil, den Pollack gemessen hat.



    Die CPU- und Netzlast auf dem Client und dem Server ist auch bei diesem Test im niedrigen einstelligen Prozentbereich, so als ob die Threads innerhalb der C-API wirklich nur auf ihre gegenseitige Synchronisierung warteten.


    Augenblicklich läuft dieser Agent ca. eine Stunde. Wie kann dieser Agent denn noch auf mindestens 200 Docs / sec. beschleunigt werden?


    a--

  • Lausige Performance von Multithreaded Java-Agenten.

    ... googlen hilft ...


    Andrew Pollack kommt zu einem noch verheerenderen Ergebnis bei der Verwendung von Multithreading mit separaten Sessions verglichen mit einer Session:


    Multithreading-Artikel von Andrew Pollack




    Ich lass' das jetzt einfach mal so stehen und versuche es morgen mit einer shared-Session über alle Threads.



    a--

  • Lausige Performance von Multithreaded Java-Agenten.

    Sigh - ich drücke mich wohl manchmal sehr missverständlich aus.


    Da hätte ich gleich von Anfang an mehr auf das Zahlenverhältnis zwischen Read und Write hinweisen müssen ( und es ist ja hoffentlich unstrittig, daß nur Writes die Indizes verändern).


    Hier mal ein Snippet des Logs des soeben laufenden Tests:


    Code
    2007-02-15 04:40:54.515  INFO1 : 18 Docs / sec. (3 von 50059 gespeichert) bei 36 Threads
2007-02-15 04:41:24.451  INFO1 : 18 Docs / sec. (10 von 50772 gespeichert) bei 36 Threads
2007-02-15 04:41:54.387  INFO1 : 18 Docs / sec. (19 von 51529 gespeichert) bei 36 Threads


    Die 18 Dokumente / sec. sind inklusive der Zeit zu interpretieren, die es braucht, die Hashtables und Threads zu initialisieren.


    Bei der Single-Threaded-Version waren es etwa 12 Dokumente pro Sekunde.


    720 Dokumente in 30 Sekunden sind also runde 24 Dokumente pro Sekunde. Da hätte ich schon eine Zehnerpotenz mehr erwartet.


    Zu den gespeicherten Dokumenten: Es sind also gerade mal 0,3 Promille der Grundmenge gespeichert worden.


    Und diese 0,3 Promille der Grundmenge aller Dokumente sollen dafür verantwortlich sein, daß in einem Thread ein getDocumentByUnid() mehrere Sekunden dauert und daß alle 36 Threads gerade mal 24 Dokumente pro Sekunde schaffen, wo sonst ein getDocumentByUnid() in einer hunderstel Sekunde durch ist?


    Das ist ja noch viel schlimmer als zunächst befürchtet. Was, wenn dieser Agent im kleinen einstelligen Prozentbereich Dokumente verändern muß?


    Die Dokumente selbst, die in diesem Agenten bearbeitet werden, sind obendrein nicht sehr groß. Bei einem anderen Agenten mit etwa 5 mal mehr Feldern dieser Dokumentenklasse kommt der Agent auf noch nicht mal 10 Dokumente pro Sekunde.


    Und Einstellungsmöglichkeiten sind somit erst gleich garnicht zu erwarten, wenn ich den bisherigen Thread hier in der Retrospektive so lese?



    a--

  • Lausige Performance von Multithreaded Java-Agenten.

    Zitat


    Natürlich gilt das nicht, denn wenn du dir ein Dokument holst und gleichzeitig eines veränderst müssen z.b. entsprechende Ansichten aktualisiert werden und auch das kostet Zeit.
    Und vor allem wenn du mehrere Threads verwendest kann sich das ganz schön hochschaukeln.


    Dem widerspricht aber die Beobachtung, daß zwei unterschiedliche PCs, die hälftige Teilmengen bearbeiten, die halbe Zeit brauchen.


    Ich hätte mich obendrein noch viel mehr gewundert, wenn ein Index mit einer so hervorragenden Dispersion der Werte, wie eine DocID sie darstellt, so herbe Probleme hätte. Aber dies ist nicht der Fall.


    Nebenbei würden wir bei einer Index-Aktualisierung obendrein einen höheren Server-Load beobachten. Auch das ist nicht der Fall. Ebensowenig wie IO-Waits auf dem Disk-System.


    Obendrein wird nur eine sehr geringe veränderte Teilmenge der Dokumente überhaupt gespeichert. Der Flaschenhals ist aber getDocumentByUnid() mit ca. 95% der Laufzeit - und das schreibt - hoffentlich außer in irgendwelchen RAM-Buffern - nix ;)


    Zitat

    schon gesagt: Wenn du per sInitThread einen neuen Thread aufmachst, dann tust du das über die Domino Java Klassen, d.h. dieser greift nicht mehr direkt auf den Server zu sondern über die entsprechenden externen Klassen und damit gelten auch alle Regeln für den lokalen Notes Zugriff in diesem Artikel.


    Aber da simmer wieder beieinander. :)


    Welche Einstellungen auf dem Client kann man vornehmen, um diese Begrenzungen aufzubohren?


    Ich mag es nur schwer glauben, daß die Client C-API, über die wir letztendlich reden, dort einen dermaßen fetten Lock über dem native Call sitzen hat oder daß es gar nur einen statischen Buffer für Dokumente gibt, der dann über die Threads hinweg synchronisiert werden muß.


    Obendrein ist dieses Verhalten von Multithreaded-Java-Agenten und dem dicken Performance-Malus beim Multithreading sowohl in R5 als auch in R7 zu beobachten.


    a--

  • Lausige Performance von Multithreaded Java-Agenten.

    Genau - und dort in dem Artikel steht auch:


    Zitat


    Within a session, Domino Objects are shared, synchronized, and recycled across threads. Using a different session on each thread loses these capabilities; you must explicitly manage synchronization and recycle on a per-thread basis.


    Einstellungen - soweit dort in den beiden Artikeln aufgeführt - betreffen ausdrücklich DIIOP und die Webservices auf dem Server. Diese sind jedoch nicht aktiviert. Welche nicht-DIIOP betreffenden Einstellungen konkret meintest Du, sollte ich überprüfen?


    Da alle Workerthreads jedoch eine eindeutig abgegrenzte Teilmengen bearbeiten, sollte man doch annehmen, daß die Synchronisierung für die Funktionen aufgehoben ist und man den vollen Durchsatz erhält.


    Insbesondere für das getDocumentByUnid() scheint dies nicht zu gelten.




    a--

  • Lausige Performance von Multithreaded Java-Agenten.

    Hallo auch,


    recht herzlichen Dank für die Antwort.
    Werden denn UniversalIDs auch in Ansichten gehalten, so daß man diese dann "refreshen" muß, um mit getDocumentByUnid() darauf zuzugreifen? Wäre mir neu.


    Zu den NotesThreads: Jeder Worker initialisiert einen eigenen NotesThread und startet eine eigene Session auf dem Server. Man sieht dann auch schön, im Notes-Log, daß sich nach dem Ende der Worker-Sessions mal eben 20 User auf einen Schlag abmelden.


    Code
    // Neuen Notes-Thread aufmachen...
NotesThread.sinitThread();
SESSION=NotesFactory.createSession();


    Das hätte ich auch zuerst vermutet, daß über dem einen NotesThread ein fetter Lock liegt.


    Interessanterweise ergibt das Bearbeiten von zwei gleich großen Teilmengen der ca. 40.000 Dokumente enthaltenden View an zwei verschiedenen Rechnern eine um den Faktor 2 verringerte Laufzeit, so daß man den Flaschenhals ohnehin auf dem Client vermutet hätte. Das war überhaupt erst der Anlass für den Ansatz, um mit Multithreading die Laufzeit verkürzen zu wollen. 20 Threads ergeben aber ebenfalls nur eine Verkürzung der Laufzeit um den Faktor 1,5 bis 1,7 und nicht 10, wie ich ursprünglich mindestens erwartet hätte.


    a--

  • Lausige Performance von Multithreaded Java-Agenten.

    Hallo miteinander,


    einen habe ich hier noch, über den ich noch nicht so recht drüberkucke:


    Gegeben ist ein Java-Agent, der sich über eine View eine Reihe von UniversalIDs zieht und damit eine Hashtable füllt.


    Wenn eine Hashtable eine gewisse Anzahl von UNIDs enthält, wird mit dieser Hashtable und einer neuen NotesSession ein Worker-Thread gestartet, der dann die eigentliche Arbeit über dieser Teilmenge von Dokumenten übernimmt. Nach dem Start eines Workers wird eine neue Hashtable mit wiederum 2000 UNIDs gefüllt und der nächste Worker angestoßen, bis die komplette View abgearbeitet ist. Auf diese Weise werden ca. 20 Threads gestartet, die dann 2000 Dokumente pro Thread abarbeiten sollen.


    Das Abholen der Unids geht rasend schnell.
    800 UNIDs pro Sekunde sind kein Problem. Der Server jammert dort dann etwas von 20.000 Transactions/Minute aber das soll so sein. ;)


    Das eigentliche Bearbeiten der Teilmengen in den Workern jedoch enttäuscht ungemein. Der Client, auf dem der Agent läuft, hat eine CPU-Auslastung von 20% und einen Netzwerktraffic von noch nicht mal 100k/sec.


    Der Server (Unix) hat während dem Lauf der Worker einen Load von 1 und einen Netz-IO, der gerade mal einer 10MBit Netzwerkkarte gerecht wird. Die Durchsätze im Nicht-Notes-Bereich erreichen jedoch problemlos 10 MBYTES/sec.


    Das SCSI-Raid zeigt einen Disk-IO von nicht mal 3 MB/sec an. Gemessen wurde mit Bonnie jedoch auf diesem Server ein Disk-IO von 50MB/sec. Entsprechend ist auch die im wait() verbrachte Zeit auf dem Server recht niedrig.


    Der Server hat während dem reinen Worker-Lauf nur noch ca. 3000 Transactions / Minute.


    Beim Profiling des Agenten ergab es sich, daß die in den Workerthreads aufgerufene Funktion getDocumentByUnid() mehr als 95% der Zeit verbraucht. Wenn man einen einzelnen Worker-Thread im Debugger von Eclipse durchsteppt, bekommt man auch durchaus Wartezeiten von 10 Sekunden und mehr, wenn diese Funktion angetriggert wird und andere Threads hingegen "normal" laufen.


    getDocumentByUnid() ist normalerweise als rasend schnell bekannt, da sie direkt über die DocID das entsprechende Dokument aus der Datenbank beziehen kann?


    Wieso braucht getDocumentByUnid() jedoch in einer Multithreaded-Anwendung auf einmal so lange? Und wieso wird hierbei der Server und der Client nicht mehr belastet? Kann man irgendwelche Einstellungen vornehmen, die diese Funktionen etwas mehr aufpeppen, wenn sie multithreaded laufen? Oder liegt da über der API ein dermaßen breiter und wenig granularer Lock, daß nichts geht, wenn eine Notes-API-Funktion aufgerufen wird?



    a--

  • Standalone-Applikation in Java hört bei 7.0.2 auf zu funktionieren.

    Zitat


    Akane schrieb:
    seit der V5.0.11 lief der u.g. Code zum Öffnen einer Notes-Datenbank auf einem Server vom Client aus ohne Probleme:
    ...
    Auf einmal jedoch weigert sich "lnSession.getDatabase(Server, Database)" auf einem 7.0.2er Client zu funktionieren. Auf einem 7.0.1er Client - mit den ansonsten gleichen Einstellungen und Berechtigungen - funktioniert dieser Code zum Öffnen einer Datenbank jedoch wie gewünscht.


    Problem erledigt. Der Fehler trat auf den Plätzen auf, die den Designer nachträglich installiert bekommen hatten.


    Diese Designer-Installation legte im Programmverzeichnis eine notes.ini ab, die von der abwich, die bei uns im data-Verzeichnis liegt. Interessanterweise wird beim Start von Notes die notes.ini verwendet, die im Data-Verzeichnis liegt, von den Standalone-Anwendungen jedoch die notes.ini, die zuerst im Pfad gefunden wird.



    a--

  • Standalone-Applikation in Java hört bei 7.0.2 auf zu funktionieren.

    Einen schönen guten Morgen miteinander,




    seit der V5.0.11 lief der u.g. Code zum Öffnen einer Notes-Datenbank auf einem Server vom Client aus ohne Probleme:



    Auf einmal jedoch weigert sich "lnSession.getDatabase(Server, Database)" auf einem 7.0.2er Client zu funktionieren. Auf einem 7.0.1er Client - mit den ansonsten gleichen Einstellungen und Berechtigungen - funktioniert dieser Code zum Öffnen einer Datenbank jedoch wie gewünscht.


    Der Effekt ist der, daß zwar ein instantiiertes und initialisiertes Datenbankobjekt in "lnDB" zurückgeliefert wird, dieses Objekt jedoch nicht verwendbar ist, da lnDB.isOpen()==false ist.



    Greift man auf dieses lnDB-Objekt dann im weiteren Verlauf zu, entsteht die folgende Exception:


    2007-02-09 03:03:34.739 INFO1 : Lese Systemprofil profil_replika_ewb
    NotesException: Database Servername!!Database.nsf has not been opened yet
    at lotus.domino.local.Database.NgetProfileDocument(Native Method)
    at lotus.domino.local.Database.getProfileDocument(Unknown Source)



    Obwohl beim getDatabase()-Call ausdrücklich ein Server angegeben wurde, ist bei einer Messung des Netzwerktraffics auf dem Server kein Netzwerktraffic von dem Client aus feststellbar. Selbstredend ist die restliche Connectivity zwischen den beiden Clients und dem Server tadellos.


    Da dieser Code am Anfang dieser Woche auf R7.0.2 auch schon mal funktionierte, kann es sich somit nur um eine Einstellung auf dem Client bzw. um eine Policy-Geschichte handeln.


    Frage: Welche Einstellung kann dafür verantwortlich sein, daß getDatabase() auf einmal nur noch lokale Datenbanken versucht zu öffnen und den Serverparameter ignoriert. Interessanterweise findet auch keine Frage nach dem Passwort statt und ein testhalber eingebautes lnSession.getUsername() liefert '' zurück.


    Bevor die Frage auftaucht: "logMessage()", "logError()" und "logStacktrace()" sind Funktionen zum Protokollieren, die keinerlei Bezug auf lotus.domino.*-Klassen nehmen und von daher seiteneffektfrei sein sollten.


    a--

  • Persistente Doclinks seit R7

    Zitat

    In der ganzen Prozedur wird nur die k:l-Relation verändert. Die k:m-Relation wird nicht angefasst. Dennoch zeigt auf einmal nach dem Speichern das k:m auf eine ganz andere Dokumentenklasse als vorher, so als ob in dem k:m Richtextitem ganz andere Werte stehen würden.


    Das gilt nach wie vor.


    Einen SPR, der mit diesem Phänomen zusammenhängen könnte, habe ich bei IBM gefunden:


    Code
    http://www-1.ibm.com/support/docview.wss?uid=swg27008587


    Dort ist unter der Nummer: JSHN6KPP8G


    (wörtlich zitiert ;-): "...Fixed problems which prevent link corruption...."


    Sonderbar nur, daß trotz der etwas unikaten Beschreibung des Fixes der Fehler sowohl mit 7.0.1FP1 als auch mit 7.0.2 auftritt und daß diese Regression mit der 6.5.5 implementiert wurde.


    Ist von dem Phänomen hier wirklich noch niemand gebissen worden?



    Akane--

  • Persistente Doclinks seit R7

    Einen schönen guten Abend miteinander,



    derzeit sitze ich vor einem kniffeligen Problem, das sich mir nicht recht erschließen will, nicht zuletzt auch, weil es in der Testumgebung nicht auftaucht und in der Produktion massiv für zerstörte Referenzen sorgte.


    Eine Dokumentenklasse "k" relationiert über Doclinks eine Dokumentenklasse "l" und "m".


    k:l ist wie 1:n (für n>=0)


    k:m ist wie 1:m (für m>0)


    Ändert sich nun in der Beziehung k:l die Anzahl der relationierten Dokumente, wird sinngemäß wie folgt verfahren:


    1.) Backend-Dokument des UIDoc holen: kDoc=UIDoc.Document


    2.) Das RichtextItem im kDoc über getItem holen und mittels Item.remove löschen.


    3.) Ein neues Richtextitem rtItem im k-Dokument erzeugen.


    4.) Aus den informell in einem Mehrfachwerte-Textfeld gespeicherten DocIDs das neue RichtextItem mittels rtItem.appendDoclink(lDoc,"") aufbauen.


    5.) Nach der Schleife über die Texteinträge: rtItem.update


    6.) saveoptions="0" im Backend-Dokument setzen.


    7.) Ein neues UIDoc im aktuellen Workspace mittels
    set UIDocNew=ws.editDocument(kdoc)
    erzeugen.


    8.) Das alte UIDoc schließen und vernichten: UIDoc.close() und Delete UIDoc.


    9.) Das neue UIDoc speichern.


    Das ganze funktioniert erstaunlicherweise sogar zunächst ganz gut, obwohl ich nie verstanden habe, wieso der Programmcode im alten UIDoc nach wie vor noch läuft, obwohl das alte UIDoc doch gerade gelöscht wurde. Ich hätte da spontan eine Schutzverletzung erwartet, aber es funktioniert und damit gut. :oops:


    Seit der R7-Umstellung nun haben wir das folgende Phänomen:


    In der ganzen Prozedur wird nur die k:l-Relation verändert. Die k:m-Relation wird nicht angefasst. Dennoch zeigt auf einmal nach dem Speichern das k:m auf eine ganz andere Dokumentenklasse als vorher, so als ob in dem k:m Richtextitem ganz andere Werte stehen würden.


    Dieser Effekt tritt sowohl unter R7.0.1FP1 als auch unter R7.0.2 auf.


    Gemeinerweise nur in der Produktion und nicht im Test. Die ganze "fixup, compact, updall"-Orgie ist selbstredend schon gelaufen. Auch ein Anlegen einer neuen Replik - sowohl über den Client als auch über den Server brachte keine Veränderung.


    Momentan behelfen wir uns damit, daß wir nach einer Veränderung jedweder Relationen in den Dokumenten ein "MachneueRelationen" aufrufen. Das ist allerdings ein starker Performance-Hit und nicht wirklich schön. Besser wäre es, wenn Notes die Relationen, die nicht berührt werden, gleich garnicht veränderte.


    Hat diesen Effekt schon mal jemand beobachtet? Wie habt Ihr das gelöst?



    Akane--