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
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 Uni
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
Kevin,
It sounds as though the server is seeing the disconnects, but the client is
not getting the response back to recognize that it is truly disconnected.
Therefore the object is waiting on a response. I am not sure if the
driver is thread safe, but I would not count on it.
I might suggest p
