in einer Kundensituation ist folgendes Phänomen aufgetreten:
Aufgrund von gemeldeten Performance-Problemen, wurden die Produktiven enaio Applikations-Server überprüft. Hierbei ist aufgefallen, das die „ostemp“ Verzeichnisse teilweise mit über 100k *.xml Dateien gefüllt waren.
Hintergrund:
Das ostemp wird von verschiedenen OS-nativen Komponenten für „temporäres“ zwischenspeichern verwendet. Nutze ich z.B. im Workflow-Skript eine DB-Abfrage Richtung Server, so wird das Recordset als XML im ostemp gespeichert.
Nach verarbeitung der Daten ist es demnach dringend geboten, die Ergebnisdatei (Recordset) explizit zu löschen.
So weit, so gut.
Nachdem wir jetzt aber alle Stellen im Skript entsprechend angepasst haben, füllen sich die ostemp-Verzeichnisse immer noch, aber offensichtlich mit „Zwischenergebissen“ aus Talend-Importstrecken.
Die Instanz „Drei_ImportServiceAuftrag_PROD“ ist definitiv ein aktiver Talend-Job.
Jetzt stellt sich uns die Frage, wie wir in Talend-Jobs einrichten können, das diese temporär Dateien gelöscht werden.
Ich würde mich über eine kurzfristige Rückmeldung freuen, da die betroffene Strecke pro Tag rd. 10.000 Dokumente verarbeitet und zu jedem Import mind. 1 *.xml Datei auf dem Server „liegen bleibt“.
Mittelfristig wäre es spannend zu wissen, warum die Importkomponente die Files zurücklässt, wird der Job 10’000x am Tag gestartet (und stürzt am Ende ab/wird abgebrochen) oder ist es ein grosser Import?
Hallo @herbrand, noch eine Rückfragen: Ist in der Strecke auch eine Anfrage verbaut, und wenn ja, welche Komponente? enaioSearch oder enaioGetResultList?
Hallo @rk ,
Powershell: das ist unser aktueller Workaround
Bzgl. den anderen Fragen:
Keine Search-Komponenten im Einsatz.
Der Job wird alle paar Minuten gestartet, holt die neuen Importdaten ab und verarbeitet diese
Meine Vermutung ist, das die xml’s von der Import-Komponente stammen, welche bei „Import and Search“ Einstellung ja im Hintergrund auch eine Suchanfrage auslösen.
Ich kann dir gerne einen solchen Job bereitstellen, möchte den aber aus Gründen nicht hier einfach „hochladen“.
@rk Will ich dir ja gerne glauben und kann da fachlich auch nur bedingt gegen halten. Aber, ich habe ostemp Verzeichnisse, welche innerhalb von wenigen Tagen mit eben immer wiederkehrenden xml-Strukturen tausendfach erzeugt werden und liegen bleiben.
An anderem Server werden aus einer anderen Konfiguration ebenfalls ebensolche xml’s erzeugt.
EnaioClientLib-*.jar ist von uns/Teil der Talend Components for enaio®
enaio-rpc-*.jar ist von OS/Teil von enaio®
Völlig klar, ich habe nur noch keinen Lösungsvorschlag dafür und meine Zwischenergebnisse dokumentieren wollen.
Die XML-Dateien sehen für mich sehr nach Antworten der enaio®-Server-API auf DMS.GetResultList aus, also wie etwas, was bei den enaioSearch- oder EnaioGetResultList-Komponenten ausgelöst wird, aber nicht bei EnaioImport, welches lediglich DMS.XmlImport auslösen sollte. Wäre es möglich, mir einen Screenshot der Strecke oder die Strecke zukommen zu lassen?
Hallo @herbrand, ist wirklich verrückt. DMSContent sind die Ergebnisse von enaio® für GetResultList oder GetObjectDetails, soweit ich weiss.
Gibt es eventuell ein Server-Event, welches GetResultList oder GetObjectDetails oder Ähnliches aufruft bei Importen? Unsere JAR ruft das wirklich nur in den Search-Komponten auf:
