Idea/Suggestion: Take a look at DOS CMD / Unix CMD "netstat -an" output on the Server. If you see a significant amount of sockets in "TIME_WAIT" state, you may need to add the "TcpTimedWaitDelay" parameter to the Registry, (for Windows). There are ways to modify this in various Unix platforms - you'll need to dig out the particulars for your 'nix variant.
A lot of applications will call/open a socket, send data, then close the socket, rather than re-use, and then call a new socket next time. When next connection is opened, or a lot of connections are opened, perhaps the Server does not have the "free resources" to clean up these connection/sockets that are lingering around, as the OS is designed to perform such clean up in the background when it has the capacity to do so. Busy Servers may not be able to free up these resources as fast as they're being called/used. (This behavior exists across all Windows and Unix platforms). For Windows, you can add a Registry setting called "TcpTimedWaitDelay" which does not exist by default, but it does use a default parameter, (240 I believe). which may be way too long for many/most applications, especially if applications do not "re-use" alread opened socket/ports. By adding this parameter as specificed in the MS TechNote, and setting its value to "30" decimal (i.e. "30 seconds"), this will help free up significant amounts of ports stuck in "TIME_WAIT" state in a significantly faster manner, proving in more smooth server & network operations and sockets availabilty. http://technet2.microsoft.com/windowsserver/en/library/38b8bf76-b7d3-473c-84e 8-e657c0c619d11033.mspx?mfr=true I have seen this behavior numerous times, across numerous applications and across numerous platforms, verticals, etc... I hope this helps. Regards, Scott Richardson Senior Systems Engineer / Consultant Sr. Product Support Engineer Marlborough, MA 01752 Email: CheetahFTL at comcast.net **************************************** DPMonitor - http://www.deltek.us ----- Original Message ----- From: "Kevin King" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, May 28, 2008 12:07 PM Subject: Re: [U2] Re: ODBC Connection Hanging Around > Well, the CLOSE appears to have been a red herring. Everything ran fine for > several hours, then all at once a half dozen sessions didn't get > disconnected. And again it appears to have been when there were a lot of > simultaneous sessions. I'm leaning more and more to a threading issue with > the Unidata ODBC driver. > > On Wed, May 28, 2008 at 8:15 AM, Kevin King <[EMAIL PROTECTED]> wrote: > >> The client terminates fine. It's the server session that doesn't >> disconnect. And in a weird twist that I'm still watching, I added a generic >> CLOSE statement to close all the files being used by the subroutine before >> it returns to the caller and since making that change the server has not >> left any connections open. But like I said, I'm still watching this to see >> if this was the silver bullet or merely a coincidence. ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
