We have a java server application running on Redhat Linux 8.0 that accepts transactions over TCP/IP and processes those transactions by connecting to Microsoft SQL Server (running on another machine, obviously) using Microsoft's SQL Server JDBC driver.

This app also uses sockets to communicate between three separate JVMs that may be on different servers (but are all on the same server in this case).

Over time, the number of open file descriptors held by the java processes grows until it reaches the per-process limit imposed by Linux. At this point the application fails due to the inability to obtain more file descriptors. This usually manifests itself as an inability to open a new database connection.

The app's VMs are currently using native threads.

When I observe the actual file descriptors in use over time, here is what I find:
- Each java thread has descriptors for all the java .jar files and libraries it needs, as well as any Linux libraries it needs. This number remains very constant over time.
- Each java thread has descriptors for the sockets or serversockets it has open. This number also remains constant over time.
- Certain threads (the ones that acquire and use connections to the database) have a number of file descriptors open to files of the form /tmp/scb_<n>.tmp where <n> is a number with a variable number of digits (e.g. /tmp/scb_58474.tmp). The number of these files that are open grows over time, and is roughly equal to the number of transactions that have been processed.

Clearly, the scb_* files are the problem. Our code is not creating these files. I am suspicious that the MS SQL Server JDBC driver might be, but I don't know that yet.

Has anyone seen files like these before, and do you have any idea where they're coming from?

Hi,
wow!
that does sound odd. you could try this rm -f scb_*.tmp and see who, if
anyone, complains. If this is a mission critical server and you have no
fallover or backup you may want to try something else first. But then again,
if it is mission critical you'll need to resolve the problem ASAP. So........
Well, have you tryed catting the file or running strings on any of them just
to see if you get info from them? try and see if not.
let me know what happens.
Michael

Michael,
Thanks for your response.

Shortly after I posted my question, our customer decided to put the Linux port on hold, so we've moved all their transaction processors back to Windows 2000.

In the process, I was able to show that it was indeed the Microsoft SQL Server JDBC driver that was creating the scb_* files. It exhibited the same behavior on Windows 2000.

Hopefully in the not-too-distant future we'll be porting the transaction processors back to Linux. I think we'll try a different JDBC driver then. Who know, by then the database servers might be Oracle on Linux...

Thanks,
Darrell

Kool,
Give MySQL on Linux a try.
Much better and faster then Oracle.
good luck