lefever
11-24-2002, 06:29 PM
i have a lot of CLOSE_WAIT's accumulating.
i've read in various places online about what to do about them: reboot. (or at least re-start the relevant app)
i eventually found an old message from Richard Stevens, himself (of "TCP/IP Illustrated" fame) in which he quotes some kernel code (not Linux, evidently) in which he seemed to think he'd found the cause of the CLOSE_WAIT bug
nevertheless, during site development (involving PostgreSQL, incidently) repeated re-starts of the webapp using a certain connection-pool (DDConnectionBroker) seems to be causing the accumulation of CLOSE_WAIT's
isn't there some way to reset the TCP/IP module at the cmdline?
i've thought of perhaps unloading and then reloading that module (assuming it is in its own module), but i worry about dependencies. i presume the app (PostgreSQL, in this case) woud need to be re-started anyway, to re-start its server-sockets
any feedback would be much appreciated
i've read in various places online about what to do about them: reboot. (or at least re-start the relevant app)
i eventually found an old message from Richard Stevens, himself (of "TCP/IP Illustrated" fame) in which he quotes some kernel code (not Linux, evidently) in which he seemed to think he'd found the cause of the CLOSE_WAIT bug
nevertheless, during site development (involving PostgreSQL, incidently) repeated re-starts of the webapp using a certain connection-pool (DDConnectionBroker) seems to be causing the accumulation of CLOSE_WAIT's
isn't there some way to reset the TCP/IP module at the cmdline?
i've thought of perhaps unloading and then reloading that module (assuming it is in its own module), but i worry about dependencies. i presume the app (PostgreSQL, in this case) woud need to be re-started anyway, to re-start its server-sockets
any feedback would be much appreciated