My customer has IDM and IDM drivers on Solaris and we are running out of file descriptors. We are a aware of the 256 limit and would like to know how many are used by IDM and IDM drivers.
IDM is going to consume at least:
1 file descriptor per enabled driver for TAO file + 1 more temporarily when the TAO file needs to be shrunk but still has events left in it.
1 file descriptor per trace file at driverset or driver level.
2 file descriptors per driver for the writeback queues.
1 file descriptor per open socket.
1 file descriptor per file that any particular driver has open.
Note that the problem only exists when using the fopen/fread/fwrite/fclose I/O API. The replacement code that eDir uses for this family of functions no doubt requires that any code making these function calls be recompiled because the size and offsets into a structure have been changed.
For the TAO files I believe we use a lower level API that while does consume file descriptors, does not stop working when the file descriptors exceed 256. The rest of the open file descriptors are going to come from Java code for which we have very little control over what underlying API is used - that would be mostly determined by what Java itself uses, which I suspect is also the lower level I/O. That leaves the only other possible culprits being JNI layers used by API's consumed by driver such as Notes, SAP, JDBC & JMS with certain 3rd Party drivers, etc. Again we have no control over these, but the obvious solution here would be to run the driver in a remote loader where it will have it's own pool of file descriptors instead of sharing the pool consumed by eDir.