too many files open

All,

We’re running IS4.6 on a Windows 2000 machine and running into the “too many files open” issue. I’ve read a couple of other discussion threads on this topic which all seem to deal with controlling the number of files that the repository creates.

I have two questions that are slightly different:

When the Integration Server starts, it attempts to open every file in the repository. The problem is, once the number of files in the repository exceeds the maximum, you can no longer start the Integration Server. In this case, how do you clear out the repository?

Finally, an alternate approach to solving this problem (short-term as it may be) is to increase the number of files that the operating system can have open. Does anyone know how to do this in windows 2000? I’ve read about the config.sys and the config.nt files, but these don’t seem to be the answer.

Thanks for the help!

After doing steps below you will loose client certificate configuration and if you had some customize TN webmanager pages those also. So before doing the step below please consider…Is it your dev/uat/prod box?

In order to avoid that again you should install the TN service pack and after installing that you will see it will runa schedular on your server which cleans the repository file after a specified interval.

Hope this will help.

Steps:

  1. Take the backup of WmRepository folder under your b2b server directory
    2.Delete the WmRepository folder
  2. Restart the b2b server

It will create the new directory while startup.

Cheers
MJ

Are you referring to the <webmethods>\IntegrationServer4\WmRepository2 directory? If you are you can run the wm.tn.enumerate:deleteQueryResults to clean up files in the WmRepository2 directory.

Permanent solution move to database based repo or Unix.
Also, deleting repository wud cause other problems if using RNIF.

webMethods support can provide u with a package to list contents / update /delete contents of repo.

Duain,
Yes I was refering to WmRepository2 file and you can use wm.tn.enumerate:deleteQueryResults to clean up but I don’t know if this service will help him now since his server is already messed up with open files. It would be a good idea to put this service as a schedular once he build the new repositary.

Regards,
MJ

All,

Thanks for the responses…

We are unable to run any webMethods services because the repository server will not start. So running deleteQueryResults is not an option.

We explored the option of simply creating a new repository (e.g. deleting all of the files that were in there), but this causes major problems with conversations. If there are any conversations in running status (over 200 in our case), the repository file cannot be deleted without causing errors.

We’re finding that the only real path to proceed is the one suggested by Ritesh. The database is the ideal long-term solution. We’re currently working with webMethods support to clean the file based repo manually, which entails using a webMethods utility. This is a pretty painful process…

> “too many files open” issue

Hmm… isn’t this an OS issue really?

You should be able to tweak a Windows setting to increase the number of filehandles available to the webMethods server process. At least that’s what we do in Unix to avoid this error (use the ulimit command).

It is a combination of an OS issue and a webMethods issue…

It is definitely an OS setting to increase the number of files that can be opened, though we cannot find this setting in Win2K. There is a parameter in config.nt, but it is set to 40 by default and we are not running into issues until we hit 1000 open files or so. If anyone has an explanation as to whether these two numbers are related, I’d be interested to hear.

On the webMethods side, we know that the repository does not need all the files it has open so we needed a way to clear out enough files to get the server running. We managed to do this by deleting about 100 files using a utility (webMethods support provided but we modified) that also removed the appropriate entries from the dirValuesHash file. Luckily, none of these files were associated with open conversations so no errors were generated. This wasn’t the ideal solution because it was a calculated risk that we would corrupt the repo, but it worked.