Too many open files

[jimbojones34]

Hallo,

ich probiere mal das Problem so genau wie möglich zu beschreiben. Leider bekomme ich bei meinem Tool, nach längerer Laufzeit die IO.File Fehlermeldung: "Too many open Files" Ich meine 34 steht da auch noch bei. Habe den genauen Wortlaut leider gerade nicht da, dafür müsste das Tool erst wieder Stunden laufen.


Zum genaueren Problem:
Ich starte einige male

Runtime.getRuntime().exec(externes Programm)

Insgesamt schließe habe ich alle Input- und Outputstreams. Ist alles im finally block. Jetzt habe ich mir das Tool schon mit JProfiler angeschaut und interessanterweise werden die

java.io.FileInputStreams

und

java.io.FileOutputStreams

sukzessive mehr. Das kann ich mir einfach nicht erklären. Öffne den Stream, arbeite drauf und close sie dann wieder. Von daher dürfe das nicht mehr werden. Gleiches gilt für den java.io.FileDescriptor.

So, das Problem in Kürze, ich hoffe man versteht worum es geht.

Mir sind jetzt die Ideen ausgegangen, hat vielleicht wer noch ‘nen Vorschlag oder ne Idee für mich?

 

[Spacerat]

Das könnte an so einem Konstrukt liegen (ich verwende mal ein simples Beispiel mit Strings):

for(int n = 0; n < 1000; n++) String tmp = "irgendwas";

Das hat zur Folge, das "tmp" bei jedem Durchlauf neu definiert und initialisiert wird. Ne Menge Arbeit für den "GC" die Ex-Definition sammt zu eliminierender Referenz wieder zu finden. Die Lösung sieht etwa so aus:

String tmp = null;
for(int n = 0; n < 1000; n++) tmp = "irgendwas";

Auf diese Art bleibt die Ex-Definition erhalten, und der "GC" kann die alte Referenz sofort eliminieren, wenn sie nicht noch woanders verwendet wird.

mfg Spacerat

 

[didjitalist]

solche lokal definierten, kurzlebigen objekte kann der GC extrem effizient wieder abräumen. hat aber mit dem thema an sich nichts zu tun. ich tippe eher drauf, dass die streams doch nicht geschlossen werden, oder du zu schnell, zu viele descriptoren anforderst, die das zugrundeliegende FileSystem nicht schnell genug wieder freigeben kann.

 

[jimbojones34]

Mh okay, das gucke ich mal nach, denke aber, das ich das schon so gemacht habe wie dein Vorschalg. Führt das denn, falls es nicht so gemacht ist dazu, das die FileInputStreams, FileOutputStreams und FileDescriptore so ansteigen, ich meine, der GC müsste dann doch, zwar langsam, aber irgendwann ja doch mal den Müll wegwerfen oder?

ich wollte das Limit an Files unter Linux auch hochsetzen, aber irgendwie kennt der Rechner den ulimit Befehl nicht. Aber selbst wenn, dann wäre das keine gute Lösung.

 

[Spacerat]

der GC müsste dann doch, zwar langsam, aber irgendwann ja doch mal den Müll wegwerfen oder?

Ja... das dachte ich auch mal... bis ich meinen Code mal durch 'nen Profiler gejagt habe. Soviel zur "Effizienz" des "GC" und dazu, dass mein voriger Beitrag nichts mit dem Thema zu tun hatte.

mfg Spacerat

 

[jimbojones34]

Okay, dann gucke ich mir das mal an. Dann ist es allerdings schwer, den Fehler einzugrenzen, denn wenn auch Varibalen was mit dem FileInputStream usw. zu tun haben, dann kann das ja jede Schleife usw. sein. Klar ist mir das aber echt noch nicht, was normale Varibalen mit den Streams zu tun haben.

 

[didjitalist]

mag ja sein, dass der GC die nicht sofort wieder wegschmeisst, aber mit dem problem hat es trotzdem nicht zu tun. bleib bei meiner vermutung, dass irgendein stream halt doch nicht geschlossen wird. vielleicht der error stream, den liest ja normalerweise eh niemand ein

 

[jimbojones34]

Eine besch.. Sache, muss ich mich mal durch den Code schaue. Das habe ich schon und eigentlich meine ich alles zu schließen, aber der Errorstream ist mal wieder ne neue Möglichkeit

 

[Gelöschtes Mitglied 5909]

ich hatte das gleiche problem auch mal, es lag nicht daran dass ich die Dateien nicht geschlossen hatte sondern dass ich zwischendurch zu viele offene dateien hatte. Du musst versuchen dass du die Anzahl der gleichzeitig offenen filehandles verringerst. Bei mir ging das damals indem ich die ankommenden daten sortiert habe, vielleicht klappt ja bei dir ähnliches. Das Problem trat bei mir auch nur unter Linux und nicht unter Windows auf, was mich anfangs verwirrt hatte.

 

[Wildcard]

Der GC ist sicherlich nicht das Problem. Wenn der Stream richtig geschlossen wird, wird auch das File Handle geschlossen, das ist völlig unabhängig davon wann denn nun das Stream Objekt vom GC eingesammelt wird.

 

[Guest]

Der GC ist sicherlich nicht das Problem. Wenn der Stream richtig geschlossen wird, wird auch das File Handle geschlossen, das ist völlig unabhängig davon wann denn nun das Stream Objekt vom GC eingesammelt wird.

So würd ich das auch sehen, ich mache den Stream auf und dann wieder zu, daher ist es mir ja so ein Rätsel, wieso sie die sukzessieve aufsummieren. Ich werde mich aber noch mal genau angucken müssen, was JProfiler da ganz genau in der Accomplished View anzeigt, nicht das der da auch was vermurkst.

 

[Ebenius]

Unter Linux? Wie oft machst Du denn mit exec Prozesse auf? Pro Prozess gibt es drei Ströme; 1x InputStream, 2x OutputStream. Bin mir nicht ganz sicher, aber im Linux würde ich erwarten, dass es sich im FileInputStreams und FileOutputStreams handelt. Nur eine Idee... :-/

Ebenius