| Dart Home | PowerTCP Winsock for ActiveX | Custom Development | Reply | PowerTCP Winsock for ActiveX Topics | Forums |
| Author | Forum: PowerTCP Winsock for ActiveX Topic: tcpClosing/tcpClosed not being fired ? |
| roofrack gary.roussak@tyrrellsystems.com From: Leigh, United Kingdom Posts: 23 Member Since: 06/08/06 |
posted July 2, 2009 12:22 PM Hi, I have a web server application written in VB6 which uses a PowerTCP Daemon control to hand off HTTP connections to a pool of 'worker' classes. As each new connection is made, the worker class initializes with a unique id and gives itself a TCP control which handles the socket traffic - all fairly standard stuff. In addition, I keep a little table of workers currently in memory. When I receive either a tcpClosing or tcpClosed event from the TCP control for that worker, I use it to mark the worker as 'dead'. I regularly scan the table and, if a worker has been dead for a few seconds (and thus hasn't been re-used), I remove that worker and its TCP control from memory to avoid excessive memory usage. I do everything by the book, i.e. close() calls, setting objects to nothing, and so on. This all APPEARS to work just fine. However, I also use those tcpClosing and tcpClosed events to control a different set of program resources -- to avoid lengthy explanations, lets just call them widgets. The reasoning seems logically sound - if I know when a worker and its socket are created (which I do), then I borrow a widget. If I know when a worker and its socket are destroyed (which I do via the tcpClosing and tcpClosed events), then I have the opportunity to be sure I return the widget. However, what I'm finding is that, over a period of a few days execution, I am running out of widgets, i.e. I am occasionally not returning one I have borrowed. I have looked at vast acres of logs to help diagnose the problem. The only thing I can think of is this: if the user drops their browser connection before my server finishes returning its HTTP response, then I see my TCP worker fire a 10054 error (VC reset by remote side). On this occasion, could it be that tcpClosing/tcpClosed never gets fired ? If so, this might explain the problem, because my TCP_Error event handler doesn't do any tidying up of the worker table I just described, and thus things would get out of step. Can anyone confirm this behaviour of a TCP control ? Thanks |
| Jason Farrar (Admin) From: Oneida, NY USA Posts: 223 Member Since: 07/24/07 Extra Support Options Custom Application Development |
posted July 9, 2009 5:27 PM I did some quick tests using the Web Server sample and couldn't reproduce the problem. I also saw the state being reported correctly in the state event and wasn't able to produce a 10054 (WSAECONNRESET)error. At any rate, I would suggest that when you get this error you should close down the connection and do clean up as you would if the connection were closed. ------ |
| BrendanM From: Durban, South Africa Posts: 80 Member Since: 07/11/02 |
posted July 22, 2009 11:18 AM Hi, We have seen this type of behaviour with some of our customers. In some cases the tcpClosed event never fires and our application thinks the connection is still up & running. What we found was these customers were sending us data via a serial to TCP converter (a Moxa unit). To work around this we set the KeepAlive property after we have accepted their connection, and with the appropriate registry settings. |
| Reply | PowerTCP Winsock for ActiveX Topics | Forums |
This site is powered by
PowerTCP WebServer for ActiveX
|