Beiträge von kreisbeck

Danke für die Antwort. Den Link hatte ich auch gefunden. Aber ob das wirklich gefixet ist, ist unklar. Bei unseren Entwicklern besteht weiterhin Zweifel. Wäre halt prima, wenn jemand sagen könnte: "Hey, das ist mit 9.0 aus der Welt geschafft".

JARS auf den Server schieben hat den Nachteil einen umständlichen Deployments (insbesondere wenn man einen Dienstleister hat und man nicht ohne Weiteres Zugriff auf das Filesystem hat) und natürlich das Problem beim Einsatz unterschiedlicher Versionen. Aber wahrscheinlich werden wir dabei bleiben müssen

Hallo zusammen,

der Domino-Server hat ein Problem mit JAR-Dateien, die in Agenten eingebettet werden. Der Classloader räumt nicht richtig auf und irgendwann ist der Speicher voll.

Das Thema ist auch hier beschrieben: https://www-304.ibm.com/support/docview.wss?uid=swg1LO49880.

Wir haben das Problem mit Domino 8.5.1 FP5. Weisst jemand, ob und mit welcher Domino-Version dies behoben ist?

Gruß

Deshalb suchte ich ja nach einem

"call doc.SaveWithoutTriggeringTheAMGr (...)"...

Geht da nicht irgendwas mit der API?

So eine Endlos-Schleife war auch der Stein des Anstoßes, man stelle sich das bei 250 DBs vor.

Natürlich muss dem Chaos Perfektion folgen, von daher wollte man statt der Endlos-Schleife den einmaligen Lauf.

Was wir jetzt haben:

1. Agent läuft und tut was er machen soll
2. Er wird - leider - ein 2. Mal eingeplant, läuft an und bricht sofort ab
3. Ruhe

Hi Bernhard,

wir haben das rauf und runter getestet.

UpdateProcessedDoc bevor das Doc geändert wurde, UpdateProcessedDoc nachdem das Doc geändert wurde, Dokumente in die Collection aufgenommen und in Gänze gestampt etc..

Was wir erreicht haben: Der Agent wird eingeplant, läuft aber mit 0 unproccesseddocs los, dadurch kann er SEHR früh verlassen werden.

Den Impuls, den Agent neu einzuplanen konnten wir leider nicht unterdrücken.

Zitat

Dein Problem ist schon klar.

Puh... ich dachte schon mich versteht keiner... *seufz*

Zitat

Aber die Folgerungen, die du daraus ziehst ... da machst du dir unnütze Gedanken...

Ja, gut... dann müssen wir damit leben und die Sache weiter beobachten.

"Dazu über msconfig noch UAC ausschalten." ist natürlich genauso sinnvoll wie "Einfach Firewall ausschalten" oder "immer mit root-Rechten arbeiten"

[.. gelöscht ..]

http://de.wikipedia.org/wiki/User_Account_Control vieleicht mal anschauen.

Also entweder:

- Richtigen Pfad als Data-Dir wählen
- Pfad-Rechte sezten
- Notes als Admin ausführen
- Vista Sicherheitsfeatures umgehen
- Vista meiden

Dann einfach die Recht setzen, volles REcht auf notes-Data c:\programme\notes für den Anwender. Nicht das OS ist schuld, sondern der der damit nicht umgehen kann.

Dazu über msconfig noch UAC ausschalten.

Der Agent wird trotzdem eingeplant, was bei 100ten von Datenbanken bei einem größeren Unternehmen schon zu ordentlichen Belastung des AMGrs führt.

Ablauf im Detail:

1. Ausgangssituation: Dokument wird erstellt / geändert
2. Amgr plan Agenten deshalb ein
3. Agent läuft an und ändert selbst etwas (das muss fachlich sein!)
4. Amgr plan Agent deshalb neu ein!

Punkt 4 sollte idealerweise wegfallen, dies geht aber nur wenn eine Dokumentänderung (doc.save) NICHT den AMGr antriggered.

Also: Es geht nicht darum, dass der Agent richtig läuft - das tut er, sondern das der AMGr ihn nicht nicht unnützt einplant. Und das macht er leider - unabhängig von jeglichen Auswahlformeln oder unproccessed-Listen.

Hmm.. Du hast aber mein Problem nicht erkannt.

Nicht die Agent-Steuerung mit Unproccessed-Flag etc. ist das Problem, sondern dass der AMGr bei jeglichem doc.save einen Agenten, der auf veränderte Dokumente reagiert, einplant.

Dies soll vermieden werden, damit der Agent nicht noch mal anläuft.

UnproccessedDocuments ist eine Liste per Agent, die dem Agent zur Verfügung steht - das triggern über den AMGr wird dadurch nicht beeinflusst.

Nun, es geht mir einfach darum, dass der Agent NICHT angestoßen wird.

Ich will ein doc.save innerhalb eines Agenten durchführen, ohne dass der AMGr meint, den Agenten neu einzuplanen.

Bei der 2. Ausführung des Agenten würde dann zwar nichts mehr passieren, aber er würde halt einmal sinnlos anlaufen.

Zitat

Das Problem ist die verkorkste Rechtestruktur von Vista, die es eben nur mit Klimmzügen zulässt ein Verzeichnis unterhalb des Programmverzeichnisses für User schreibbar zu machen.

Nochmal: Das Datenverzeichnis hat absolut nichts im Programm-Ordner verloren. Sämtliche Software macht das auch richtig, ob nun MS, Adobe, Mozilla... nur Notes verhält sich wie ein Windows 3.1 Programm.

Legt einfach das Dataverzeichnis plus ini in das Userverzeichnis und es läuft einwandfrei.

Ein Data-Verzeichnis innerhalb der Programmstruktur ist ein sehr unsauberes Konstrukt.

Jedes vernüftige Windows-Programm legt User-Daten im Benutzesverzeichnis ab und nicht unter Programme. Ist auch unter Unix seit eher Pflicht und kein grundlegendes Vista-Problem.

Also ab mit dem data Verzeichnis nach c:\users\<benutzer>\notes\data

Hallo,

wir haben einige Agents, die auf "wenn Dokumente erstellt oder geändert wurden" reagieren.

Allerdings schreiben diese Agents selbst wieder in die Datenbank, was dazu führt das sich der Agent über den AMGr wieder selbst anstößt.

Gibt's ne Möglichkeit das zu umgehen?

Problem ist nur, dass es genug "gewachsene Lösungen" gibt, wo halt nun mal nicht sauber mit Berechtigungskonzepten umgegangen wird.

Editor+Löschen/Erstellen ist oftmals das Standard-Recht. Klar, kann man das mit mehreren Manntagen eine Applikations re-designen und migrieren und somit sicher machen.

Aber oftmals ist der "große Wurf" einfach nicht drin und kein Budget für eine Lösung von konzeptioneller Reinheit da.

Da ist ein einfacher Agent der seinen Zweck im Falle von Editor+Löschen/Erstellen grundsätzlich erfüllt, vielleicht die sinnvollere Lösung, oder ein continue = false in den QueryPaste-Events.

Merke: "einfach" ist "natürlich ganz nett", "richtig" ist auch immer besser, aber die beste Lösung ist in Hinsicht auf Zeit und Budget selten drin.

Naja, sicherlich kann man das alles über Agenten realisieren und jede Funktion durch bessere, sicherer und komplexere Lösungen ersetzten.

Trotzdem kann auch ein Autor z.B. per Agent aus einer anderen Datenbank über das Backend Items ändern, die er über die Maske gar nicht ändern könnte und somit diverse Regeln aushebeln.

Um wirklich sicher zu gehen, dürfte wirklich nur der Server persistente Daten ablegen, Usereingaben müsste vorher entsprechend validiert werden.

Die Lösung mit berechtigem Schreibagent ist natürlich ganz nett.

Einfacher gehts mit dem Agent

"When Documents are pasted" (Der im Deutschen falsch übersetzt wurde, da Passiv und Vergangenheit verwechselt wurden).

Dim s As New NotesSession
Call s.CurrentDatabase.UnprocessedDocuments.RemoveAll(True)