Re: Bad File Number Closing.....

Question

Just a thought-
Is this Windows? Make sure you have a large enough "FILES"
parameter in your CONFIG.SYS, etc. I seem to recall problems similar
to what you describe when we didn't have it high enough.
Make sure to re-boot after changing the "FILES" parameter..
Also, if you encounter or generate exceptions, be very careful to
catch them and close open files! Otherwise in the course of testing your
application you will slowly use up the available file handles and get
problems more often. Quitting the application (in the
Development Workshop) does not free the handles --
Quitting Forte completely does.
Hope this helps.
-Greg
To: forte-users <[email protected]>
From: Michael George <[email protected]>
Date: 8 Nov 96 14:59:43
Subject: Bad File Number Closing.....
Reply-to: Michael George <[email protected]>
Has anyone ever encountered the Bad File Number error when closing a file
object. This is a random error that is causing us major grief. We can run our
application 6 or 7 times before we eventually receive the bad file number error
when executing the "close" method. Incidentally, this same error occurs when
you import a new project into your workspace, and then try to import the exact
same project again (overwriting the first one).
We tried using the "Flush" method before closing, we also tried deleting the
text file after we closed it each time. But nothing seems to be helping. Any
help would be appreciated.
Greg Nyberg, Senior Consultant
Born Information Services Group
Phone: [phone] Fax: [phone]
------------------------------------------------------

Answer 1

Thanks for your prompt answers.
Are your two processes on two different hosts accessing a common NFS file system? If so, all bets are off.We have processes from multiple (hundreds in fact) boxes accessing common NFS system. With a careful design of one process accessing BDB at a time, we have pretty good success. Millions of BDB GET/PUT per day are succeeding just fine. Occasionally we see this bad file number error in different scenario of GET/PUT/CLOSE.
Came up on the following article in a google search which indicates that a JDK bug may be causing this behavior.
http://256.com/gray/docs/misc/java_bad_file_descriptor_close_bug.shtml
We are running 1.5.0_11-b03 currently. We will try to upgrade the JDK and see if the problem goes away. Upgrading is a slow process though.
The cleaner is the only thing that deletes a log file so it must be running somehow.We are explicitly disabling cleaner by setting e.env.runCleaner to false. Let me know, if the cleaner can still run somehow.
Does closing the environment in all threads of the process that receives the exception and then reopening the environment clear the problem? Note that unless you do Environment.close() on all Environment handles, the Environment will not get truly closed. In cases when GET and CLOSE fail because of "Bad File Number", things are recoverable. When PUT fails because of "Bad File Number", we are loosing user data which is bad.