Agents frieren ein, nachdem Daten via webservice (SAP) importiert wurden

[DaHias]

Hi zusammen,

Im Namen einer Kollegin poste ich hier ein Problem, auf das wir aktuell stoßen.

Situation
Wir nutzen immer mehr Webservices zur Kommunikation zwischen SAP und Lotus Notes. Wir haben bereits einige im Einsatz, die alle funktionieren, jedoch haben wir nun 2 neue eingeführt, die beide Probleme bereiten. Der Webservice entsteht durch den Import eines WSDL-Files aus SAP, so dass an diesem selbst nichts mehr geändert wurde. Der Webserive wird dann anschließend durch einen Agenten aufgerufen.

Problembeschreibung
Es gibt unterschiedliches Verhalten bei unseren beiden neuen Agenten:

1. Agent importAsset: Import von ca. 9000 Datensätzen aus SAP via webservice (hochsetzen der Parameter HTTPJVMMaxHeapSize=1024MB, JAVAMAXHEAPSIZE=512MB war nötig) benötigt nach der eigentlichen Verarbeitung (5 Minuten) noch über 20 Minuten zum Beenden. Im Taskmanager braucht die nlnotes.exe 50% CPU, wobei die Speicherauslastung schrittweise um 16 KB runtergezählt wird. Dauer: ca. 25 Minuten.

2. Agent importEmployeeData: ca. 1600 Dokumente werden aus einer view gelesen und für jedes Dokument ein webservice aufgerufen, der Daten aus SAP holt. Verarbeitungszeit: 7 Minuten, Wartezeit nach der Verarbeitung: 50 Minuten. Hier ist vollkommen unklar, womit er sich beschäftigt, da hier kein Speicherproblem besteht - es wird ja immer nur pro webservice-Aufruf ein Datensatz aus SAP geholt.

Es scheint also so zu sein, dass der Webservice nicht sauber geschlossen wird, jedoch gibt es auch keinerlei Möglichkeit dem Agenten zum Beenden zu zwingen. Beide Agenten laufen weit über die eigentliche Verarbeitung hinaus noch weiter und belasten das System, ohne dass man in den Logs etwas sehen könnte, was hier passiert.

Hatte schon jemand mal so ein Problem? Weiß jemand, wie man am Ende die Sitzung beenden kann oder den angsammelten Speicher wieder freigeben kann?

Umgebung

• Lotus Notes 8.5
• SAP ERP 6

Vielen Dank für Tipps!

Grüße,
Mathias

[ghostmw]

Hast du schon mal das Logging deaktiviert oder auskommentiert ?

Ich denke, er wurschelt sich zu Tode bei den möglicherweise vielen logAgent.logAction(..) Einträgen bei der Anweisung "Call logAgent.close()"

[DaHias]

Danke für das Feedback!

Das hatten wir schon einmal ausprobiert. Wir haben alle logAgent.logAction(..) entfernt, aber der Effekt blieb leider der gleiche.

[ghostmw]

Ok, nächster Punkt wäre das verwendete Objekt doc.

Das wird x-Mal neu angelegt nach dem Speichern in der Schleife.

Recycle das bitte mal nach der Zeile "Call doc.Save(True, False)" mit "delete doc".

Vielleicht ist die Menge der neu erstellten NotesDocument-Objekte ein Problemchen, ich vermute hier einen möglichen Ansatzpunkt.

[DaHias]

OK, wir haben nun am Ende des Save jedes mal "delete doc" ausgeführt, jedoch hängt der Agent nun trotzdem wieder fest, so dass auch das wohl leider keine Lösung zu sein scheint. Schade

[ghostmw]

Die wsimportasset.txt ist das gleiche wie die importasset.txt -> Absicht oder Fehler ?

[DaHias]

Ah stimmt, danke für den Hinweis!

Anbei die korrekte Datei.

[m3]

Uh, da wuerde ich auf jeden Fall auch einen PMR bei IBM aufmachen.

[DaHias]

Da haben wir nun schon seit 2 Wochen einen laufen, aber bis jetzt konnten die uns nicht wirklich weiterhelfen. Daher hatten wir gehofft dass vielleicht Leute aus der Praxis schon Erfahrungen mit so etwas gesammelt haben.

[DaHias]

Hiermit nur an alle, die evtl. mal auf das gleiche Problem stoßen: IBM konnte das Problem nun endlich (nach x Anläufen) nachstellen und es wurde dazu ein SPR aufgemacht.

Wie lange das nun dauert weiß ich leider nicht.

[pram]

klingt ähnlich diesem Problem:
http://www-10.lotus.com/ldd/r5fixlist.nsf/Public/B03340A15E2BD8A7852577DE0005C24A?OpenDocument

Damit musste ich auch schon mal herum schlagen. Die Agenten beenden sich dann manchmal nicht sauber, wenn Objekte im Speicher hängen, durch Delete (wie Marko schon geschrieben) oder Aufbrechen der Referenzen kann man dagegen abhelfen.
(Bsp: Objekt A kennt B und Objekt B kennt A, damit ist die LS-Garbage Collection überfordert und beide Objekte bleiben im Speicher)

Gruß
Roland

/edit: So wie es aussieht, scheint "exEquitab" ein relativ komplexes Objekt zu sein. Implementiere hier und in den Unterobjekten ggf. mal eine "shutdown()" Funktion, welche rekursiv alle Unterobjekte über das baldige Ableben informiert, und setze in jedem Objekt die Referenzen zu anderen Objekten auf "Nothing".

[flaite]

Es gibt alternative Lösungen mit Java-Programmierung in Notes, die ich verschiedentlich erfolgreich eingesetzt hab.
Ähnlich wie hier: http://atnotes.de/index.php/topic,52899.0.html nur ganz anders.
Ihr könnt mich als externen Berater buchen, oder wir machen das einfach hier für umsonst. Ich hab nach den vielen erfolgreichen Anläufen nun begonnen ein erweiterbares Framework zu schreiben, dass für alle diese Remote-HTTP Fälle eingesetzt werden kann, für die die Bordmittel in Notes nicht ausreichen. Praxisfälle sind dabei willkommen.
Erster Schritt wäre, dass Du mit soapUI, XMLSpy oder verwandtes ein Request Sample für die wsdl erstellst und es mir per persönliche Nachricht schickst. Alternativ könntest Du auch einen SOAP-Monitor zwischenschalten, der die Nachrichten intercepted und weiterleitet.

Den import Employee Fall könntest Du vermutlich lösen, indem du per Agentenlauf nicht die gesamte View durchläufst, sondern nur jedesmal ca. 10 Dokumente und pro Dokument ein flag setzt

Code

doc.webservice_verarbeitet = "1"
call doc.save (true, false)

Und eine neue View, die nur solche verarbeitet, in dem doc.webservice_verarbeitet != "1"
Dann den Agenten mehrmals laufen läßt.

Für den ersten Fall ist aber schon ziemlich klar, dass die Lotus Axis1 Lösung sehr reale Grenzen im Hinblick auf die Skallierung hat.

Gruß

Axel

[DaHias]

Update:

Antwort von  IBM in Kurzfassung bei einem solchen Problem:

So again, the 2 options here.

1)  Use LotusScript, and manage Soap messages with under 100k objects
2)  Use Java which seems to be more consistent with small, or huge soap
messages