3 Replies Latest reply on Aug 1, 2003 9:59 AM by Jim

    Lots of (network) file descriptors on Linux

    Mike Finn Apprentice

      Our production environment (JBoss 3.2.1 on RH 7.2) has a ton of FDs open - specifically network connections. lsof shows 265,000 IPv4 descriptors open, and it grows every day. Our server has been up for about 2 weeks.

      Almost all of these connections are something connecting to/from HSQL port. We do use HSQL for clustering and JMS persistence.

      The number just seems very high, and I am pretty sure the server will soon puke once the OS can't open any more FDs.

      Any ideas?

      Mike

        • 1. Re: Lots of (network) file descriptors on Linux
          Jon Barnett Master

          Not quite sure why there are that many connections open. If your clustering requires external connections, you might not be able to do this. But we run hsqldb without using the JDBC port.

          You can configure in the hsqldb-ds.xml that it runs-inline.

          <connection-url>jdbc:hsqldb:default-db-name</connection-url>

          rather than:
          <connection-url>jdbc:hsqldb:hsql://localhost:1701</connection-url>

          Probably more of a work-around than a solution if it does work.

          I checked our configuration with lsof and it does seem to show the same problems - but we don't run clustering. It's been running four weeks.

          • 2. Re: Lots of (network) file descriptors on Linux
            Jon Barnett Master

            I forgot to add that you can disable the HypseronicDatabase MBean with the in-process or in-memory modes.

            • 3. Re: Lots of (network) file descriptors on Linux
              Jim Newbie



              I've seen this too on the machine that we use JMS on. We have other (identical setup's) of jboss 3.2.1 that have the JMX running but not in use.


              I'm going to make a guess here and say that there is some jboss bug between JMS and the HypseronicDatabase that causes to to keep opening connections and not closing.