Making Sure All Resource Released

[BrendanChandler]

I have an ASP app that has been running fine for months on several client systems. This week one of their ISPs pulled the plug on the site saying that it was draining resources on the shared server and therefore it needed shutting down. The most likely code was 'poor' programming resulting in leaving resources open on the server.

I am always very careful to

recordsetname.close
set recordsetname = nothing
con.close
set con = nothing

at the end of all the ASP scripts, including the names of all the recordsets I have used. The app is, however, quite large and being human it is possible to miss one occasionally. I have found one recordset not being closed and corrected this but am still battling with the ISP to a) get the site up again and b) for him to provide more information about what scripts, tables etc are involved in the problem.

I am concerned that the code has been running for months on this site unchanged without problems and for months with at least 8 other customers on other shared server sites with with much more traffic and several of them with this same ISP who has not complained about the other sites.

In order to cover myself I would like a 'belt and braces' approach to slip in a routine, perhaps in a common footer file which is included at the bottom of all my scripts. I wanted to include some code that would check if the record set still exists, if so is it open and if so close it and release it. Is this a practical solution and if so what might the syntax look like?

I have tried

if isobject(recordsetname) = true then
recordsetname.close
set recordsetname = nothing
end if

but it seems that if recordsetname has already been release the isobject still returns true which is totally misleading!

I also considered another approach which suppresses all errors then attempts to close all tables and release objects even if they have already been released e.g.

on error resume next
recordsetname.close
set recordsetname = nothing
con.close
set con = nothing

Obviously each of the examples above will list all possible recordset names that might be used anywhere in my application

Are either of these solutions practical or is there a much neater way to ensure in a footer include file for example that all resources have been released (I must say I find ASP and Windows 2003 in this area rather primitive that it cannot simply close everything automatically when a script finishes or have a short timeout to release resources - a simple command CLOSE DATA ALL has been doing the job in FoxPro for over 15 years now and all I am trying to do is put some of that functionality on the web!)

Any help here really appreciated. Thanks

 

[Sheco]

You might try the IF Not MyObj Is Nothing THEN syntax but I'm not sure that is any better than what you've already suggested.

I'd want to look at the windows perf mon logs to see what exactly they are complaining about.

Make sure your code doesn't put objects into Session/Application variables, that can lead to memory usage problems ... it doesn't scale well.

If you've tried everything and still no luck then you could just wrap ADO inside an ActiveX DLL that you build with VB... and then install the DLL into COM+. This trades a little bit of overhead for more managed objects that you can pretty much count on being released from memory when you're done with them.

 

[BrendanChandler]

Sheco,

Thanks for that. I will try the new syntax and ask for a look at the windows perf mon logs if they will let me see them and assuming they will mean anything to me! I do use session variables to keep track of who is logged in. There are only 2 or 3 per session and my understanding is they are released after 20mins by default anyway if the user fails to log out and release them that way. When you say doesn't scale well - what volumes are you describing. Are we talking 1000s of current users? This site I suspect would never have more than 20 or 30 people looking simultaneously and we have other sites using the same code that are in the low hundreds at peak times. We only use about 6 app variables containing key path information which can be read when the data tables containing same info are temporarily unavailable because new versions are being uploaded. Activex sounds like a steep learning curve best avoided until the current crisis is over. Thanks again

 

[Sheco]

Ah I wasn't trying to warn you away from application and session variables in general... just against putting Objects into them... specificially ADO recordset objects are sometimes tempting to put there... these chew up a lot of memory but probably not something you'd notice at the small user loads you describe... unless those other sites on the same box really have the server bogged down or the hardware is weak.

 

[BrendanChandler]

I see. No I don't put any objects in either session or app variables. They are kept to very small character strings. I can only think it is the db access that is causing the issue but because there are no complaints from other sites with much bigger loads using the same scripts I suspect that we might have a small leakage but for some reason are being blamed for a much bigger one on the shared server caused by someone else who they are not easily able to identify. That's my hunch by I cannot prove it and so am stuck with trying to lock my system down as tightly as possible. I found 1 recordset on a popular page which was not being closed when everything around it including the con object was but had been like that for months without comment. I am not sure how many hits like that it takes to bring a shared server to its knees in order for the ISP to take such drastic action and why does a modern operating system like Windows 2003 not time these resources out after a few minutes anyway? The number of users is not high afterall. Thanks again

 

[ChrisHirst]

the best way to prove it is to have your sites application protection set to Isolated in the IIS MMC.
This puts the site into running in it's own process context (DLLHOST) and memory space and if there is any leak only your site will stop.

If the server still bogs down it's someother site

Chris.

Indifference will be the downfall of mankind, but who cares?
Woo Hoo! the cobblers kids get new shoes.
People Counting Systems

So long, and thanks for all the fish.

 

[BrendanChandler]

Chris,

Thanks for that. I asked the ISP if something like that were not possible. Their response was that implementing this itself has a massive overhead and because each site is given a limited amount of space you end up unable to get as many sites onto the shared server because inevitably their is some balancing between some sites requiuring lots of resources and others requiring very little. Less sites on the server and your costs go up!

Note had any more complaints from the ISP since fixing 1 recordset closure. Not convinced that was the problem as discussed earlier and the ISP has not given me access to any logs. He did say that the problem went through to lines of support before a 3rd more experienced technician was able to pinpoint our site on a report.

I feel that we have had a rude awakening here though and will be moving to a dedicated server shortly so that we are not at the mercy of the ISP has we have been.

Thanks for everybody's comments.

 

[ChrisHirst]

Yep, a move sounds a good idea.
I'd be a little concerned about a host loading down a server so much that they couldn't isolate sites even as a short term process.


Chris.

Indifference will be the downfall of mankind, but who cares?
Woo Hoo! the cobblers kids get new shoes.
People Counting Systems

So long, and thanks for all the fish.