"Invalid file handle" bei Zugriff auf MIMEEntity

[masseur81]

Hallo,

per Notes API lade ich Dateien aus einer MIME Entity eines Dokumentes. Das Ganze passiert im Kontext eines Webcontainers, also multithreaded. Nun bekomme ich bei mehrmaligem Zugriff folgende Meldung:

  NotesException: invalid file handle
   at lotus.domino.local.MIMEEntity.NgetContentAsBytes(Native Method)
   at lotus.domino.local.MIMEEntity.getContentAsBytes(Unknown Source)

Woher kommt das?

[Ralf_M_Petter]

Sind alle Threads für die Verwendung von Notes initialisiert?
Verwendest du in jeden Thread ein eigenens Session Objekt oder Sharest du es über mehrere Threads.
Verwendest du recycle()?

Bitte poste doch mal Codefragmente sonst kann man nur schwer was sagen.

Grüße

Ralf

[masseur81]

Also Codefragmente kann ich nicht liefern, ist alles ziemlich verstreut (wie bei OO eben normal).
Aber ich kann sagen, dass ich nur eine Session in mehreren Threads verwende, dass ich schon darauf geachtet habe, immer brav zu recyceln. Und die Threads müssen initialisiert sein, sonst könnte ich nicht auf das Dokument zugreifen.

Mir ist halt nicht klar, was diese Meldung bedeuten soll. Es klingt ja schon irgendwie nach Zugriff der Notes-Objekte auf das Dateisystem. EmbeddedObjects werden ja glaub ich auch als temporäre Datei abgelegt. Aber ich finde einfach keinen Hinweis darauf.

[Ralf_M_Petter]

Wenn du die Session über mehrere Threads hinweg benützt wird das sicher zu Probleme führen. du schreibst das ganze funktioniert im Kontext eines Webcontainers. Was soll das genau heissen reden wir hier von Servlets oder JSP. Bitte gib mehr Infos, dann kann ich auch besser helfen.

Grüße

Ralf

[masseur81]

Ich geb mir Mühe mit den Infos. Wie du sagst - im Kontext eines Webcontainers heißt aufgerufen im Servlet, also in separaten Threads bzw. in einem Thread-Pool.

Ich habe doch aber mal gelesen, dass die Objekte einer Session synchronisiert sind. Quelle war glaub ich die Doku selbst.

[Ralf_M_Petter]

Aber du kommst durch das Recycle in Teufelküche wenn du ein Session Objekt verwendest. Du bekommst nämlich dann immer die selben C++ Objekte.

Wenn jetzt dann in dem einen Thread das Objekt recycelt wird, dann bekommst du im anderen Thread plötzlich ganz komische Fehlermeldungen. Eventuell sogar solche wie du bekommst. Aber ohne Code kann man das natürlich nicht beurteilen.

Hier noch ein Auszug aus der Doku als Beleg:

If you create more than one object to represent the same Domino element, recycling one recycles all. For example:
View v1 = db.getView("All");
View v2 = db.getView("All");
v1.recycle(); // also recycles v2
Results are undefined if you attempt to use a recycled object. No error is guaranteed.

Übrigens ich empfehle bei Verwendung des Domino APIs in Servlets unbedingt am Ende des Servlets die Session zu recyceln, da man sonst unter Garantie Memoryleaks zusammenzimmert, auch wenn man noch so aufpasst.

Grüße

Ralf

[masseur81]

Was heißt "am Ende des Servlets"? Am Ende eines Requests oder beim Zerstören des Servlets am Ende der Applikation?
Wenn ich aber am Ende des Requests ein Session.recycle() aufrufe, dann muss ich mich bei jedem Request neu verbinden (Performance), muss dann auch zwischen den Requests synchronisieren.

Also momentan ist es so:
1. Ich erzeuge die Session in einem beliebigen Thread und nutze diese in allen anderen mit.
2. Ich rufe NotesThread.sinitThread() NUR vor dem Sessionaufbau auf, also nicht explizit in jedem Thread. Trotzdem kann ich auf diese Objekte in anderen Threads zugreifen. Ein Aufruf in jedem Thread ist hier auch schwierig, da die Threads vom WebContainer verwaltet werden (ThreadPool).
3. Wenn ich (aus Versehen) ein Objekte recycle, obwohl ein anderer das noch nutzt, dann lade ich das Dokument wieder aus der Datenbank. Ich erreiche das durch Kapselung und entsprechende Abfragen.

Bisher läuft das auch ganz gut, aber wie gesagt, diese Meldung beim Zugriff auf MIMEEntities ist das einzig störende bisher.

[Ralf_M_Petter]

Deine Vorgehendsweise ist Grundfalsch und sicher der Grund warum es nicht funktioniert.

Du MUSST jeden Thread in dem du Domino Objekte lokal verwenden willst NotesThread.sinitThread aufrufen. Du sollst am Ende eines Requests die Session recyceln. Übrigens Eine Session ist sehr schnell wieder da. Das aufwendige ist das NotesThread.sinitThread. Auf unserer Homepage wird es genauso gemacht. Alle unsere Seiten sind komplett dynamisch. Alle Bilder werden dynamisch aus einer Dominodatenbank geladen und auch alle Texte sind variabel und kommen aus einer Domino Datenbank. Du kannst ja mal die Performance testen http://www.artweger.at

Grüße

Ralf

[flaite]

Vielleicht wird das MIMEEntity Objekt irgendwo in der Session gecached und dann benutzen 2 Threads die gleichen von dem Objekt gemanagten Ressourcen.
Um solchen echt nervigen Problemen aus dem Weg zu gehen, würd ich Ralfs Vorschlag in jedem Fall folgen.
Du siehst dann ja, ob die Session-per-Request-Strategie wirklich merkliche Performance-Nachteile mit sich bringt.

[masseur81]

Okay, also die Performance ist bei mir nicht so gut. Aber ich teste das mal, indem ich die Initialisierungen und Session-Recycling über einen Filter in die Hand nehme.

Im Übrigen noch die Empfehlung bei deiner Seite, den Content-Type-Header bei den Bildern zu setzen, z.B: beim Aufruf von http://www.artweger.at/app1/Image?link=4A421A6B3605745DC1256C6700430AFE&ti=67493717

[Ralf_M_Petter]

Was meinst du im speziellen mit den Content Type Header bei den Bildern zu setzen. Das mit den Bildern auf diese Art machen wir erst seit ein paar Tagen so dynamisch. Früher haben wir Sie im Apache zwischengespeichert. Treten bei dir im Browser irgendwelche Probleme auf. Bei unseren Tests sind nämlich keine aufgetreten.

Grüße

Ralf

[masseur81]

Die Probleme machen sich nur bemerkbar, wenn du die URL zu den Bildern direkt aufrufst.
Dein Browser fragt dann irgendwas mit "Speichern unter...", anstelle das Bild anzuzeigen. Das deutet auf einen Header-Fehler in der HTTP Response hin. Entweder fehlt der Content-Type (am wahrscheinlichsten) oder es ist explizit ein Header drin, der zum "Download" zwingt (heißt glaub ich Content-Disposition.

Evtl. kann das beim Aufruf der Seite in anderen (exotischen) Browsern zu Problemen führen. Auch das Caching oder der HTTP Server werden davon beeinflusst. (Z.B. lässt sich einstellen, dass - wenn kein Header vorhanden, dann text/plain rausgeben)
Ist kein großes Problem, denn sonst hättest du es schon bemerkt. ;-)

[flaite]

Vielleicht gibts noch den Weg, dass du die MIMEEntity in ThreadLocal legst? 

[Ralf_M_Petter]

Danke für den Hinweis, aber es war eine explizite Anforderung, dass er beim Direktaufruf eines Bildes diese Vorgehendsweise macht, damit das auf unserer Bilderdownloadseite so funktioniert. Aber ich werde mir mal überlegen, ob ich es so gestalten kann, dass es nur dort wo es Sinn macht so läuft.

Übrigens wenn du mal ein Demoservlet mit Code posten kannst, dass nicht so performt, dann kann ich dir gerne ein paar Tricks verraten wie wir es gemacht haben. Ich glaube ich bin ganz gut darin, da wir dass ja imerhin schon seit R5 so machen.

Grüße

Ralf

[masseur81]

Danke für das Angebot. Eine Frage hab ich nun noch: Nachdem ich mit meiner Strategie auf einen OutOfMemoryError gestoßen bin, zwei Fragen:

1. Wenn ich ein Document recycle, dann ist das C-Objekt weg, die Java-Referenz auf das Document behalte ich aber noch. Was belegt davon nun den (meisten) Speicher?

2. Am Ende eines Requests kann ich die Sessions recyceln, aber NotesThread.stermThread() kann ich da nicht aufrufen, weil derselbe Thread ja bei einem weiteren Request wiederkommt. (ThreadPool) Wo soll ich das dann bitteschön überhaupt aufrufen? Habe die Erscheinung, dass mein Application Server (WAS6.1) abstürzt, wenn ich nach NotesThread.stermThread() wieder NotesThread.sinitThread() aufrufe. 

[flaite]

Wenn du OutOfMemory bekommst, hast du einen verbotsmässig groben Fehler in deinem Anwendungs-Design.

zu 1) die Javareferenz belegt Speicher in der JVM. Das JNI gemanagte Objekt fast gar nicht im Sinne von unmerklich wenig.
zu 2) Hä? Notes-Objekte, auf die du recycle aufgerufen hast, kannst du nicht mehr verwenden.

Du rufst im doGet() oder doPost() von deinem Servlet NotesThread.sinitThread() (tendentiell am Anfang) und NotesThread.stermThread() am Ende. Du wirst kaum NotesObjekte in verschiedenen Threads sharen können. Mach alles was du mit Notes kommunizierst lokal in diesen Methoden.

Ich glaub Looseleaf hat so etwas wie einen ThreadPool für Notes-Objekte angeboten (http://tinyurl.com/5sa8el). Das ist allerdings für CORBA Verbindungen und nicht für local. Ausserdem hat mal jemand behauptet, es wäre buggy -> weiss nicht ob das stimmt.

Die Objekte der Notes-API sind einfach nicht thread safe. Deshalb geb ich deinen Versuchen sehr geringe Chancen auf Erfolg.

[masseur81]

> zu 2) Hä? Notes-Objekte, auf die du recycle aufgerufen hast, kannst du nicht mehr verwenden.
Ich cache eigene Objekte, die eine Referenz auf das Document besitzen. Vor Verwendung des Documents wird aber geprüft, ob es noch gültig ist. Falls nicht, wird es neu ermittelt.

Mittlerweile verwende ich die Sessions pro Thread, speichere die Sessions in einem ThreadLocal.

[flaite]

Mittlerweile verwende ich die Sessions pro Thread, speichere die Sessions in einem ThreadLocal.

Und wenn du das machst, kannst du die Sessions und alle Notes-Objekte sowieso direkt lokal instantiieren und einfach überhaupt nix cachen.
Afaik kann eine Session mit einem NotesDocument (oder einem anderen NotesObjekt) nichts anfangen, wenn es nicht mit der gleichen Session instantiiert worden ist. Bin mir ziemlich sicher. Aber nicht 100%.
Die MemoryOutOfBound kommt vermutlich dadurch zustande, dass deine caches zu groß werden. Aber wie gesagt, ich würd erstmal gar nichts cachen. Vielleicht hat Ralf ja noch ein paar Performance-Tricks.

[Ralf_M_Petter]

Lieber Masseeur81!

Für was schreibe ich mir hier die Fingerwund. Du darfst eine Session nicht über mehrere Aufrufe verwenden und du musst Sie unbedingt. Am Ende recyceln. Was man sich aber sparen kann, dass sind die sinitThread und stermThreads und zwar auf eine ganz einfache Weise. In jedem Servlet in dem du Notes verwendest, rufst du statt NotesThread.siniThread eine eigene statische Methode in einer eigens erstellten Klasse. In dieser Methode verwendest du eine statische hashmap in der du die ThreadIDs hinterlegst für die du notesThread.sinitThread schon gemacht hast.

Hinweis die teure Operation ist NotesThread.sinitThread und nicht das NotesFactory.createSession. Wir haben uns von der IBM einen Hook im WAS einbauen lassen, damit beim Beenden für jeden Thread ein stermThread aufgerufen wird, aber das verwenden wir nicht mehr, da wir von WAS auf Tomcat umgestiegen sind. Ist auch nicht nötig, wenn das ganze nicht lokal mit dem Dominoserver verbunden ist. Was ich sowieso nie mehr machen würde. Bei jedem kleinen Fehler hat man das Risiko, dass der Server abschmiert.

Grüße

Ralf

[Ralf_M_Petter]

@Axel!

Er hat ja bereits gesehen, dass unsere Seite extrem schnell performt, aber er will ja keinen Code von sich zeigen, damit man es anschauen könnte wo er die Performance Probleme hat. Lokal habe ich Antwortzeiten die unter 0,7 Sekunden liegen für ganze Seiten wo wirklich jeder Text und auch alle on the fly Bilder aus einer Dominodatenbank gesaugt werden.

Und nochmal am Ende eines Servletsabrufs nicht die Session zu recyceln ist Selbstmord. Da man sicher irgendwo was zum recyceln übersieht oder ein Bug in Recycle ist und schon hat man das schönste Memory leak.

Grüße

Ralf