On Thu, 8 Apr 1999, Adam Gifford wrote:
> The first night system backups were going on at the time, and these were
> changed from 8pm to midnight so they wouldn't conflict, yet the
> exception still occured last night at 9pm.
> Yesterday i used jmeter to connect to teh servlet several thousand times
> and couldn't generate the exception and i have looked through the code
> and it appears we are closing any files we have open. If anyone has any
> ideas i would appreciate them very much. Attached is a stack trace from
> our logs.
I have had to hunt down such bugs before.
Things that use file descriptors are
java.net.Socket
java.io.FileInputStream/FileOutputStream
java.sql.Connection
When you use these you have to use a finally block to recycle
the file descriptor:
Connection conn=null;
try {
conn=driver.getConnection();
...
} finally {
try {conn.close();} catch (Exception e) { /* could be null ... */ }
}
If your app is not closing its database connections. This is
independent of whether or not you are using a connection pool, although
if you are using a connection pool, I have a way of determining *which*
of its clients is(are) leaking. I will send details if you need them.
If you can afford to cycle the app periodically, then you could try
that and use a huge file descriptor limit (ulimit -n on solaris, I
think.) This is likely to keep you running longer, and is actually
the right solution if your code does *not* have a leak but just needs
a lot of file descriptors. In a multi-threaded server the number of
file descriptors that you need grows with the load, as it should.
I wouldn't worry about the specific stack trace.
----------------------------------------------
Guglielmo Lichtner (212) 799-2551
"Your quote here."
- B.Stroustrup
----------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html/>
Problems?: [EMAIL PROTECTED]
