Hi all,
Ok, first off all I need to clarify that this has been working fine for a few years, the problem appears to be with the work load and not with the code...
I have a standard .exe application that utilises an ActiveX EXE server. The application is used to ping various resources and display on screen the status of the resource dependant upon the result of the ping. The actual pinging of the resource is handled by the ActiveX server.
The ActiveX server provides a single thread-per-object multiuse class interface. Each instance of the class utilises a timer to run in a pseudo-async nature.
The application creates an instance of the ActiveX server's iface per resource ping that is required. The application then passes the target IP, frequency to ping and a timeout to the ActiveX server.
Once all of the needed instances have been created and configured the application calls a "start" procedure on the object that enables the class' internal timer.
When the timer fires in each object, the object pings the resource and then returns a response to the application via a message queue.
Right onto the problem...
I have just added a lot of new resources to monitor, taking the work load from 85 individual pings to around 200.
The problem I have is that when the application attempts to create the 161st instance of the multiuse class, VB spits out an "Out of Memory" error.
I have stepped through the code and the error is thrown when the parent application's thread accesses the 161st instance of the ActiveX's multiuse class. i.e.
I have tried stepping through the code on the 161st object instance but when I do, the IDE will not step into the ActiveX server, it just steps over; returning false and lsErrorMsg populated. n.b. lsErrorMsg is populated in the ErrorHandler of the Configure function.
Has anyone ever heard of a limit to the number of object references you can hold within VB ? Or does anyone have anyother thoughts on what the problem maybe ?
oh and it makes no difference if I am on my workstation, test bed or server.
Ok, first off all I need to clarify that this has been working fine for a few years, the problem appears to be with the work load and not with the code...
I have a standard .exe application that utilises an ActiveX EXE server. The application is used to ping various resources and display on screen the status of the resource dependant upon the result of the ping. The actual pinging of the resource is handled by the ActiveX server.
The ActiveX server provides a single thread-per-object multiuse class interface. Each instance of the class utilises a timer to run in a pseudo-async nature.
The application creates an instance of the ActiveX server's iface per resource ping that is required. The application then passes the target IP, frequency to ping and a timeout to the ActiveX server.
Once all of the needed instances have been created and configured the application calls a "start" procedure on the object that enables the class' internal timer.
When the timer fires in each object, the object pings the resource and then returns a response to the application via a message queue.
Right onto the problem...
I have just added a lot of new resources to monitor, taking the work load from 85 individual pings to around 200.
The problem I have is that when the application attempts to create the 161st instance of the multiuse class, VB spits out an "Out of Memory" error.
I have stepped through the code and the error is thrown when the parent application's thread accesses the 161st instance of the ActiveX's multiuse class. i.e.
Code:
'This works fine 161 times...
Set loObject = new MyServer.Pinger
'On the 161st call the Configure routine returns false
'lsErrorMsg contains the "Out of Memory" Error
lbReturn = loObject.Configure(lsConfXML, lsErrorMsg)
I have tried stepping through the code on the 161st object instance but when I do, the IDE will not step into the ActiveX server, it just steps over; returning false and lsErrorMsg populated. n.b. lsErrorMsg is populated in the ErrorHandler of the Configure function.
Has anyone ever heard of a limit to the number of object references you can hold within VB ? Or does anyone have anyother thoughts on what the problem maybe ?
oh and it makes no difference if I am on my workstation, test bed or server.