✔ MultiThreading: welcher Thread hält meine Datei?

[takidoso]

Hallo und Halli,
Ich habe eine etwas komplexere Datei-Konverteranwendung, die ich unter einem eigenen Thread innerhalb einer (Multithreaded) Verzeichnis-Pollenden Anwendung laufen lasse. Es kommt gelegentlich vor, dass Dateien nicht gelöscht bzw umbenannt werden (von einem Temporären auf einen finalen Namen) Da offenbar die betroffene Datei noch von etwas gehalten wird. Ansich, gehe ich den Code durch, bilde ich mir ein an allen Stellen mit finally ein entsprechendes "File.close()" zu machen. Da es recht zufällig zu passieren scheint, frage ich mich um der Sache näher auf den Grund gehen zu können, ob es denn eine Möglichkeit gibt mit irgendeiner Technik" einen Thread ausfindig machen zu können, der die Datei offenbar noch hält.
Unter Windows kann man immerhin die Prozess-ID mittels resmon ausfindig machen. Da es natürlich klar ist, dass es meine Anwendung ist, die da offenbar die Datei hält, frage ich mich nun natürlich ob man das ganze granularer hinbekommt. Vielleicht auch mit irgendeinem Statement im Code.
Gibt's sowas?

 

[ComFreek]

Hallo,

ich habe Folgendes im Internet gefunden: http://file-leak-detector.kohsuke.org/

Genau wegen den von dir beschriebenen Problemen, würde ich raten, nicht auf die gleiche Datei in mehreren Threads zuzugreifen. Idealerweise sollte ein Thread die Datei verwalten und von den anderen Threads benachrichtigt werden, um eine bestimmte Aktion auszuführen.

 

[takidoso]

Hi ComFreek,
Ohh super, der Link verspricht wirklich genau das was ich suchte.
Meine Anwendung fasst die Dateien genaugenommen nicht gleichzeitig an. wenn die logistische Anwendung (der Poll-Mechanismus) die eigentliche fachliche Anwendung (z.B. einen Konverter) aufruft benennt oder löscht er die Dateien wenn die fachanwendung fertig ist. Das einzige, was ich mir bisher noch vorstellen kann, ist dass meine eine Fachanwendung vielleicht nicht sauber schließt, aber Logs zeigen mir, dass sie das "close-Statement" erreicht hat. Ich habe nur unter Windows diese Probleme. Unter Solaris klappt das alles wie am Schnürchen. Auch andere Anwendungen die unter dem Poll-Mechanismus laufen, verhalten sich soweit problemlos.
Werde mal morgen schauen, was ich mit dem Detector alles rausfinde.

Herzlichen Dank auf jedenfall

Takidoso

Nachtrag: Ich habe tatsächlich mit dem Tool das Problem analysieren können, auch wenn es ein wenig anders reagiert als man von seiner Beschreibung annehmen würde.
mein Problem lag tatsächlich an der aufgerufenen Anwendung, in der ich versehentlich zweimal einen PrintStream für selbige Datei öffnete, da ich eine super.-Methode aufrief und dies irgendwie nicht beachtet hatte. Folge war, dass solange das PrintStream-Objekt rechtzeitig, durch den GC gelöscht wurde es keine Probleme gab, wenn aber, so war das in Windows regelmäßig der Fall, noch nach Beendigung der zusätzliche PrintStream existierte konnte das Logistische Programm natürlich die Datei nicht umbenennen.
in dem DeTector gibt es da eine nette Option, die die offenen FileHandles dumpt und zusätzlich eine Funktion diese nicht durch die GC automatisch gelöscht zu bekommen.