[Java] Too many open files

[Parasietje]

Ik draai een JBoss application server. In die application server draaien een aantal EARs, en ook een James mailserver.

Af en toe heb ik de volgende foutmelding:

code:

java.io.FileNotFoundException: /vtk/web/www/stylesheets/menubuilder.xsl (Too many open files)

Op dat moment kan de JBoss server de deployment directory ook niet meer openen, en loopt alles in het honderd. De EAR-code en de website herstellen zich echter, maar James (de mailserver) wordt afgesloten en blijft neer.

Net voor dit gebeurde, werden heel veel shell-processen na elkaar gestart. Ook werden er een heleboel files geopent, en deze File-objecten werden ook gepersist in de appserver.


Nu is mijn gok dat het volgende gebeurt (in pseudo-code):

code:

File aFile;
aFile.open();
persist(aFile);

Ik denk dat de file-descriptor nooit vrijgegeven wordt, omdat aFile nooit ge-GCd wordt, en dus ook nooit gefinalize()'t. De garbage collector denkt niet dat het nodig is om te collecten, dus een Runtime.gc() zal ook niets doen. Er is immers geheugen genoeg; er zijn te weinig FILE DESCRIPTORS.

Wat zijn jullie idee-en hierover? Is er een manier in java om alle open file descriptors te zien?

[datajuggler]

Je bent als devver zelf verantwoordelijk voor het closen van je streams, ben je er 100% zeker van dat je streams ook gesloten worden? Volgens je pseudocode niet...

Een file object is slechts een referentie naar een file, meer niet. Waarom sla je niet enkel het pad op in je databank en manipuleer je de file later pas wanneer je het nodig hebt?

[matthijsln]

Aangezien je op een unix-achtige of Linux systeem werkt kan je met het "lsof" (list open files) commando zien welke bestanden open zijn. Met "ulimit -a" (in Bash) kan je zien wat de limiet is voor het aantal tegelijkertijd open bestanden (dit is mogelijk anders ingesteld voor de user waaronder JBoss draait).

[Robtimus]

sander.devos schreef op maandag 30 november 2009 @ 19:34:
Je bent als devver zelf verantwoordelijk voor het closen van je streams, ben je er 100% zeker van dat je streams ook gesloten worden? Volgens je pseudocode niet...

Klopt. Het is dan ook erg normaal om dit soort code in een try-finally te zetten:

Java:

InputStream is = new FileInputStream(aFile);
try
{
    // doe iets met is
}
finally
{
    is.close();
}

Als je de mogelijke IOException niet wilt throwen maar catchen dan zet je daar nog een try-catch omheen:

Java:

try
{
    InputStream is = new FileInputStream(aFile);
    try
    {
        // doe iets met is
    }
    finally
    {
        is.close();
    }
}
catch (IOException e)
{
    // handel af
}

[_Erikje_]

IceManX schreef op maandag 30 november 2009 @ 20:36:
[...]

hoerige code in mijn ogen. Lees de tutorial op de sun site nog een keer goed door.

Java:

try{
... code die mogelijk een exception gooit
}
catch(Exception e){
... 
}
finaly{
... wordt altijd uitgevoerd!
}

nvm
oeps. is.close() kan ook een IOStreamException gooien... te lang geen Java geschreven

[ Voor 11% gewijzigd door _Erikje_ op 30-11-2009 21:07 ]

[Parasietje]

Het probleem is opgelost. Blijkbaar opent 'Runtime.getRuntime().exec(command)' automatisch streams voor stdin, stdout en stderr.

For prosperity:

code:

// FOUT
Runtime.getRuntime().exec(command);

// GOED
Process p = Runtime.getRuntime().exec(command);
p.waitFor();
p.destroy(); // closes stdin, stderr and stdout

// OF OOK
final Process p = Runtime.getRuntime().exec(command);
new Thread() { public void run() { p.waitFor(); p.destroy(); } }.start();