«

Hi All,

In a java process (that uses JNI and socket communications), I get "Too
many open files" error. This is on Solaris.

When debugging further using lsof or pfiles, (with the process id), I
saw many named pipes (FIFO) in open state. Output is something like,

java 17924 root 195u FIFO 0x300262429a0 0t0 800609
(fifofs) PIPE->0x300262428a0
java 17924 root 196u FIFO 0x300263ce040 0t0 800610
(fifofs) PIPE->0x300263ce140
java 17924 root 197u FIFO 0x30026243aa0 0t0 800612
(fifofs) PIPE->0x300262439a0
java 17924 root 198u FIFO 0x300264046e0 0t0 800611
(fifofs) PIPE->0x300264047e0
java 17924 root 199u FIFO 0x3008d323200 0t0 800613
(fifofs) PIPE->0x3008d323300
java 17924 root 200u FIFO 0x300264054a0 0t0 800615
(fifofs) PIPE->0x300264053a0
java 17924 root 201u FIFO 0x3007b1cf6c0 0t0 800614
(fifofs) PIPE->0x3007b1cf7c0
java 17924 root 202u FIFO 0x30026404900 0t0 800616
(fifofs) PIPE->0x30026404a00
java 17924 root 203u FIFO 0x30026405280 0t0 800618
(fifofs) PIPE->0x30026405180

We could see these entries increasing to more than 350, and then the
process crashes.

Do anyone have any ideas on how to debug further?

Regards,
Firdousi Farozan

On Tue, 04 Jan 2005 21:39:50 +0530, Firdousi Farozan wrote:
> In a java process (that uses JNI and socket communications), I get
> "Too many open files" error. This is on Solaris.

Don't crosspost to so many newsgroups. Followup set.

Obviously you haven't closed all the streams you've opened in your
code. The solution is simple: you need to explicitely close every
single stream when you are done with it, always. You can't rely on
finalization to do this for you, the garbage collector is not able to
recover external resources like file descriptors in a timely manner.

Note that not all pipes are named pipes. If you had opened named
pipes, I would expect that you would see their names in the output of
lsof, and you should be able to find their use in your code.

The fact that there are as many as 350 open descriptors seems to
indicate that you are doing something repeatedly that involves one or
more open streams. Does that ring a bell?

It is not clear from the information you've posted whether your
program crashed in Java or in a native method. If the crash occurred
in Java, where is the text of the exception? It should tell you what
the application was attempting to do that would have caused the
descriptor limit to be exceeded.

If it crashes in native code, check return values of all your system
calls, and note where it fails (and take additional system or language
questions to a more appropriate newsgroup).

For debugging, you can use ulimit to set the descriptor limit much
*lower* (to 5 or 10) so the crash occurs sooner. Choose various small
limits until you find the real source of the problem.

Since your descriptors are all pipes, I'll hazard a guess that you've
been invoking Runtime.exec() without closing the three streams
associated with the resulting Process object after the child process
is finished.

/gordon

--
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

Thanks. Calling Runtime.exec() without closing the streams was the culprit.

The problem is fixed now.

Regards,
Faro

Gordon Beaton wrote:
> On Tue, 04 Jan 2005 21:39:50 +0530, Firdousi Farozan wrote:
>
>>In a java process (that uses JNI and socket communications), I get
>>"Too many open files" error. This is on Solaris.
>
>
> Don't crosspost to so many newsgroups. Followup set.
>
> Obviously you haven't closed all the streams you've opened in your
> code. The solution is simple: you need to explicitely close every
> single stream when you are done with it, always. You can't rely on
> finalization to do this for you, the garbage collector is not able to
> recover external resources like file descriptors in a timely manner.
>
> Note that not all pipes are named pipes. If you had opened named
> pipes, I would expect that you would see their names in the output of
> lsof, and you should be able to find their use in your code.
>
> The fact that there are as many as 350 open descriptors seems to
> indicate that you are doing something repeatedly that involves one or
> more open streams. Does that ring a bell?
>
> It is not clear from the information you've posted whether your
> program crashed in Java or in a native method. If the crash occurred
> in Java, where is the text of the exception? It should tell you what
> the application was attempting to do that would have caused the
> descriptor limit to be exceeded.
>
> If it crashes in native code, check return values of all your system
> calls, and note where it fails (and take additional system or language
> questions to a more appropriate newsgroup).
>
> For debugging, you can use ulimit to set the descriptor limit much
> *lower* (to 5 or 10) so the crash occurs sooner. Choose various small
> limits until you find the real source of the problem.
>
> Since your descriptors are all pipes, I'll hazard a guess that you've
> been invoking Runtime.exec() without closing the three streams
> associated with the resulting Process object after the child process
> is finished.
>
> /gordon
>