Das Notes Forum
Lotus Notes / Domino Sonstiges => Projekt Bereich => Help-Desk Applikation !!Help!! => Thema gestartet von: Dr.Domino am 15.12.09 - 15:51:04
-
Hallo,
erstmal vielen Dank für die RC! Läuft soweit sehr gut und auch die eine oder andere Anpassung gefällt :-).
Nur der Dispatcher zickt ... wenn ich ihn manuell starte, dann rennt er innerhalb 1 Sekunde durch - ist er geschedulet, unter selbem Signer (oder auch mit dem Server als Signer), dann gibt's eine
"Execution time limit exceeded" ...
Habe schon Ein- und Ausgeknipst etc, aber hat nicht geholfen ...
-
OK die erste Frage gilt dann wie immer dem Log? Und es könnte sein das uns der altbekannte Fehler im Dispatcher schon wieder einmal durch die Lappen gegangen ist. Schau ich mir heute Abend mal an.
-
Nein, diesmal ist die Korrektur drin.
-
Nein, diesmal ist die Korrektur drin.
Wäre ja zu peinlich gewesen... bei Dir läuft er?
-
noch nicht getestet :-[
-
Hat's jemand in der Zwischenzeit mal testen können?
-
So, spannenderweise tritt ein gleichlautender Fehler seit heute auch beim "alten live"Desk auf.
Dort tippe ich aber mal drauf, daß es da ein echter "timeout" ist (dauert auch ewig, wenn ich ihn manuell strate (im Gegensatz zum 2.0RC1 timeout) ... werde mal das Limit im Server Dokument erhöhen und morgen berichten.
Denkansatz: können wir den Dispatcher nicht irgendwie dadurch beschleunigen, daß er eben nicht auf "allen Dokumenten" läuft?
Ansonsten muß wohl mal eine "Archivierungsfunktion" her ...
-
Denkansatz: können wir den Dispatcher nicht irgendwie dadurch beschleunigen, daß er eben nicht auf "allen Dokumenten" läuft?
Falscher Ansatz; die Selektion erfolgt im Code. Kannst den Agenten auch auf "Keine" stellen. Das wird aber auch nichts ändern.
Denke, da muss man mal ein Profiling machen
-
Ja, war auch mehr "ideeisch" gemeint ... die Frage wäre aber schon, ob man etwas "verlieren" würde, wennn man den Agenten nur gegen "neu und modifiziert" laufen läßt statt gegen "alle" ...
Gedacht würde ich mal sagen, alles war der Dispatcher "anfassen" muß ist ja entweder neu oder vielleicht geändert, oder?
Oder sagst Du mir gerade (und ich versteh Dich nur nicht), daß der Agent im Code _eh alles durchgeht_?
-
daß der Agent im Code _eh alles durchgeht_?
Der Code geht lediglich Dokumente mit einem Status xx durch ( weiss jetzt nicht wofür xx steht )
Er geht nicht ALLE Dokumente in der DB durch.
Ich gucke mir mal an, ob und wie man die Auswahl optimieren kann.
-
Der Dispatcher geht über einen db.search .... Wenn man den durch eine View ersetzt könnte das warscheinlich deutlich beschleunigt werden. Man bekommt aber unter Umständen auch ein Aktualitätsproblem mit neu einkommenden Tickets.
-
Also, wir selektieren folgendermassen:
sel = |@Contains(@UpperCase(Form); "MEMO":"REPLY":"NEWBUGREPORT")|
Set col = db.Search( sel, Nothing, 0 )
Hier kann es natürlich sein, dass der db.search mangels Volltextindex nicht sonderlich performant ist. Kann mir aber nicht vorstellen, daß es erhebliche Verzögerungen bei der Bearbeitung geben soll.
Man kann den db.search evtl. durch eine ViewEntryCollection ersetzen. Müsste man mal ausprobieren.
Also Ansicht bauen, die nach MEMO":"REPLY":"NEWBUGREPORT selektiert und dann die in der Ansicht enthaltenen Docs mit der ViewEntryCollection abgreifen.
Versuch macht kluch ;D
-
(Hier nochmal das Agent Log ...
Started running agent 'Dispatch' on 19.01.2010 14:44:48
Running on all documents in database: 6885 total
Found 6885 document(s) that match search criteria
ERROR: Agent execution time limit exceeded.
Ran LotusScript code
Done running agent 'Dispatch' on 19.01.2010 14:54:48
)
-
Mal für Designer-nicht-Kings ::) ... wenn ich mir also den View als
DispatchSelView
baue, dann könnte ich die col wie folgt "initiieren":
View DisSelView = db.getView("DispatchSelView ");
ViewEntryCollection col = DisSelView.getAllEntries();
Oder "paßt" dann das Ergebnis nicht für das "col", was wir brauchen?
-
Kurz gesagt ... JA
-
Also, wir selektieren folgendermassen:
sel = |@Contains(@UpperCase(Form); "MEMO":"REPLY":"NEWBUGREPORT")|
Set col = db.Search( sel, Nothing, 0 )
Warum wird bei der Gelegenheit nicht auch gleich der interessierende "Status xx" berücksichtigt?
Bernhard
-
wobei mich dein Protokoll schon wundert. Wir haben hier ein paar tausend mehr Dokumente im Helpdesk und keine Zeitprobleme mit dem Dispatcher. Das könnte also auf ein anderes Problem auf euerem Server hinweisen.
-
Also, wir selektieren folgendermassen:
sel = |@Contains(@UpperCase(Form); "MEMO":"REPLY":"NEWBUGREPORT")|
Set col = db.Search( sel, Nothing, 0 )
Warum wird bei der Gelegenheit nicht auch gleich der interessierende "Status xx" berücksichtigt?
Bernhard
Weil wir beim Dispatcher davon ausgehen, das es nur Dokumente die von außen in die Anwendung per Mail kommen trifft. Und ein Memo oder ein Reply hat keinen Status ....
-
Dann hatte ich die folgende Aussage von Ulrich mist-verstanden.
Der Code geht lediglich Dokumente mit einem Status xx durch ...
Aber heisst das im Umkehrschluss nicht, dass der Agent genau die Dokumente beachten soll, der nicht bereits verwurstet wurde (also die Dokumente, die noch kein Flag or whatever haben)?
Bernhard
-
War mein Fehler; hätte erst in den Code schauen sollen.
Wie gesagt, wirselektieren nach
sel = |@Contains(@UpperCase(Form); "MEMO":"REPLY":"NEWBUGREPORT")|
Set col = db.Search( sel, Nothing, 0 )
Nach der Verarbeitung durch den Dispatcher gibt es keine docs mehr mit diesen Form item Einträgen.
Um zu sehen, ob der Disp sich wirklich so lange bei der Selektion aufhält würde ich von uind hinter der Selektion ein Print einbauen. Das sieht man dann an der Konsole.
Aber ich vermute auch, dass das Problem ganz woanders liegt.
Es gab in der Vergangenheit mal ein Problem mit verschachtelten Tabellen. Da hat der Disp auch gerödelt und wurde nicht.
-
Da hatten wir ja beide den gleichen Zustand, Ulrich: Vorher nicht in den Code geschaut ;D
Ich konnte mir jedenfalls partout nicht vorstellen, dass Ihr keine Unterscheidung zwischen "verwurstet / unverwurstet" habt bzw. diese nicht verwendet.
Für bestimmte Aktionen verwende ich auch NotesDatabase.Search (gerade mit solch simplen Queries), obwohl ich vor dem Einsatz meist erstmal Bauchschmerzen habe. Abgearbeitet wird die Abfrage trotz sehr grosser DBs in solch kurzer Zeit, dass dies im Vergleich zu den folgenden Aktionen überhaupt nicht ins Gewicht fällt.
Wenn Ulrichs Ratschlag mit den Prints tatsächlich eine Differenz im Bereich mehrerer Sekunden ergibt, dann ist mit dem Domino bzw. der DB was faul.
Bernhard
-
Da ich da gerade schon am Code-surfen bin ...
Diese Trash-Collection, ist die "Debug-Code"
db.Search(|@Contains(Form; "grz_fghthth")|,dateTime,0)
oder wirklich live nötig?
-
Die ist live nötig weil die sammelt alle abgearbeiteten Dokumente damit die später gelöscht werden können.
-
Um sicher zu gehen, daß die "Bremse" nicht schon vor dem sel = existiert solltest du die Print statements ab dem
Set db = s.CurrentDatabase
einfügen. Vor dem sel = wird ja noch so einiges zusammengesucht. Das kann sich dann summieren ...
-
So ... die Selection ist es schon mal nicht ..
er steckt derzeit in der col. for Schleife gleich beim 1. Eintrag ...
Mehr Prints müssen her :-)
-
Aha ... dahin geht's
Call createfounddocnotificationmail(db)
und kommt nicht wieder zurück sondern hängt beim
OK=Spoofmessage
-
Print "Helpdesk-Debug-Output: Spoof - 2.1"
Do While basedoc.isresponse = True
'Print "Helpdesk-Debug-Output: Spoof - 2.2 - while"
Set basedoc = current.GetDocumentByUNID(basedoc.ParentDocumentUNID)
Loop
Print "Helpdesk-Debug-Output: Spoof - 2.3 nach while"
In diesem LOOP scheint er zu hängen ...
-
Läuft bei mir mit einem Testdocument einwandfrei. Kopiere doch bitte mal alle Documente aus der $Memo view weg und teste das mal unter kontrollierten Bedingungen.
-
So, währenddessen habe ich beim "eigentlichen" Problem, dem Dispatcher in der RC1 gewühlt ...
es hängt mal wieder mit DTCalc zusammen ...
In CreateNewTicket
set dt1 = New NotesDateTime (Now) - funktioniert
mit dem "DateTimeCalculator" nicht, die DTC Variablen stehen auf
01.01.2010
1
07:00-18:00 (07:00~18:00 ging auch nicht) ...
-
Aha! Mit "ohne" Dokumenten läuft er durch und es sind auch die neuen Tix da!
Tippen wir auf plattes Memo-Dokument?
EDIT: Memos wieder reinkopiert, die "unwichtigen" gelöscht (nur 2 echte neue Tickets dringelassen) ... hat funktioniert!
Da het er sich irgendwie an einem "was assigned to" oder ähnlichem Memo gestört ...
Merci für die Hilfe
-
Hast du die anderen noch? Die wären nämlich für die Fehlersuche mal ganz interessant
-
Dummerweise mit "Text" überkopiert ... das nächste Mal denk ich dra, die vorher in eine leer db zu packen ...
aber immer dran denken, es geht hier nicht um den 2.0er Dispatcher-Code ... vielleicht hätte es da das Problem schon gar nicht mehr gegeben ...