|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 ?
From: Leigh, United Kingdom
Member Since: 06/08/06
|posted July 2, 2009 12:22 PM
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 ?
|Jason Farrar (Admin)
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.
From: Durban, South Africa
Member Since: 07/11/02
|posted July 22, 2009 11:18 AM
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|