2.0 RC1 - Dispatcher

[Dr.Domino]

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 ...

[Thomas Schulte]

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.

[eknori]

Nein, diesmal ist die Korrektur drin.

[Tim Pistor]

Nein, diesmal ist die Korrektur drin.

Wäre ja zu peinlich gewesen... bei Dir läuft er?

[eknori]

noch nicht getestet 

[Dr.Domino]

Hat's jemand in der Zwischenzeit mal testen können?

[Dr.Domino]

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 ...

[eknori]

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

[Dr.Domino]

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_?

[eknori]

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.

[Thomas Schulte]

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.

[eknori]

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  

[Dr.Domino]

(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

)

[Dr.Domino]

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?

[Thomas Schulte]

Kurz gesagt ... JA

[koehlerbv]

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

[Thomas Schulte]

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.

[Thomas Schulte]

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 ....

[koehlerbv]

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

[eknori]

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.