Thanks to Francois, Wilfried and Angus for your kind response. For monitoring the MySrv application at service level, I have already spawning a process periodically to connect to MySrv and in case it fails, an alarm is triggered. What I am trying to do is to find the root cause.
Francois, > You can have one TWSocket connect to another one within the same > application. Just use a TTimer to do it periodically. The reason why I don't want to debug by test connecting sockets is that MySrv is already creating/killing sockets intensively everyday. Resources consumption is rather heavy and there happened several weeks before sockets were failed to created for Error 10055 - WSAENOBUFS: No buffer space available. Doing more socket connections for test I am afraid will get the application to fail faster. > It is likely the OS is out of resource, probably because there is a leak > somewhere. Very difficult to find actually. I completely will not deny the possibility of memory leak. But at the first place I would like to isolate the fact that socket listening is proper and unrelated to the problem Angus, > There is no reason for a socket to stop listening. These are very encouraging words that I love to hear > So I'd suggest your monitoring service itself tries to connect to your > listening socket once a minute sending dummy data, and then goes into a > cycle of restarting the service or rebooting the server if there is no > response over various intervals, I use five minutes for a restart, 30 > minutes for a reboot (after six restarts). When the app failed it normally takes me 10 minutes to reboot (in case serious socket error like WSAENOBUFS), or less than one minute to kill/restart the app. It depends on whether I am lucky or not, if the failure occurred at busy hours, even a two minutes service interruption will receive more than 10 complaints from customers. As I mentioned before, very demanding. :~( > it's unlikely to be an ICS problem, more likely a Windows update has > corrupted something in TCP/IP. Another good and encouraging thing I love to hear. I used to do Windows update frequently (service is maintained at a backup server of course), but I find the wsock32.dll stuff has not been updated since 2003 (the app is being run on Win2k sp4)? Now my thought (please don't mind if it is stupid), after having a glance to the WScoket source code. There is a enum TSocketState to reflect the socket status (I think?). If the TWSocket class is already getting the Windows socket status and indicates that by this enum value, then isn't it a way to check whether the socket is still listening? If the enum is indeed the winsock's state, then either I can get what I expect, or the winsock says it is listening but actually it is not, then it is a winsock problem that I have nothing to do with. Please correct me if I am wrong. Best regards, Patrick -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
