VFP temp tables not closed when EXE run as COM service on servers

[dbMark]

I've been away so long I don't recall if I asked this before...

I was on a team with about a dozen or so VFP apps compiled and uploaded to Microsoft servers back about 2015 with WSDL for COM access. Every few days our servers would crash or hang and when we logged in we found there was no memory left. We discovered that some temporary tables generated by the apps had never actually closed and so over the course of a few days the available memory gradually diminished until it was gone. As a short term fix I and a few others on the team would log in to the server a couple times a week, find days worth of tables and CDX files still open and we'd delete all but the ones generated in the last hour, just in case those recent ones were still in use.

Base on the file names I narrowed down which routines generate those temp tables. Our code definitely closed them, same pattern as reports elsewhere. We never figured out whether it was a server issue or something with VFP called by COM through WSDL. Our work was picked up by the other division using Java and totally different code, no VFP.

Does this ring a bell to anyone?

Background: I was in a Fortune 200 company and 3 divisions handled similar services. Ours was not the newest (Java) nor the worst (frequent issues), but eventually all 3 divisions were folded into one and my division closed in 2017. I was not retained. No surprise, I was by far the oldest, nearly twice their age even though I'd been there 15 years. Thereafter response to job opportunities were always "we're done to two" and then "sorry, we picked the other candidate. So in 2018 I went through a programming Boot Camp, I chose Visual Studio with C#, SQL, JavaScript, etc since I already had an overview of Java, the other course. Most were half my age and only one or two knew a little programming such as JavaScript. Most were snatched up. Me? A programmer with 20+ years experience? Ha! "We picked someone else." I did some work with Robert Half but it was more like app rollouts and related callcenter support for a week or so here and there, no programming, nothing to live on. So I've been on hiatus, sabbatical, whatever, for a while now.

 

[TamarGranor]

I've never heard of VFP leaving file open when it closes, even in a crash. Leaving temp files around, yeah, sure, but open? Not that I've ever heard of.

Tamar

 

[Chris Miller]

I wonder what you actually talk about.

If you create cursors, they might not even become temp files, but DBF() will point to %TEMP% and when RAM becomes short VFP will swap a cursor to exactly that file name - that's when it becomes slow, too, usually.

Base on the file names I narrowed down which routines generate those temp tables. Our code definitely closed them, same pattern as reports elsewhere.

That points out it's not really temp files, you may create files in %TEMP% and like Tamar I never herd of files kept open when VFP or a VFP EXE (and the runtime) closes or even crashes. Leaving them there, yes, there's no automatic deletion of files jsut because you create them in %TEMP% (or GETENV("TEMP").

Also there is no OS mechanism that removes files from %TEMP% just because processes creating them end, there's not even a purging of the TEMP dir when the OS starts.

COM works a bit different from a normal EXE, depending on what exactly you set up in the servers tab of project info. Not only the different runtimes for DLLs or EXE, mt-dlls or not.

If in-process .dll servers are deployed in a Component Services (or Microsoft Transaction Server) package, creating an instance of the server will load the .dll into the memory space of a Component Services process rather than the calling process. Moreover, multiple-process .exe files can instantiate Visual FoxPro .dll servers that will be loaded into a single Component Services process. Component Services generates or reuses a thread for each client requesting an instance (OLEPUBLIC) from a Visual FoxPro server. Since such applications often require enterprise scalability, there is the potential for many concurrent instances to access your Visual FoxPro server simultaneously. If only one client (instance) is allowed to execute code at a time, all others must wait. With a single processor machine, this may be fine, depending on the nature and execution times of methods in your server. Remember, a single processor can only run one line of code at a time.

This and some other things in the VFP help may explain why something is resident when using COM within a web service.

Here's one more sentence from a topic about the VFP9T-dll (for multi threaded DLLs):

Visual FoxPro makes it possible for the same multithreaded Visual FoxPro run-time library to be deployed with multiple, concurrently called in-process .dll automation servers whether they are in same process/thread or not. The original Visual FoxPro run-time library creates a renamed copy of the library for each in-process .dll server running in the same process.

DLLs are loaded into a main process, but they don't share the runtime, when copies of the vfp9t.dll are created and remain, that could end up in something remaining resident, though when a main exe ends all loaded DLLs should also vanish, all file handles are closed and you should be able to erase files. The question becomes what is the main process. In case you use IIS and application pools that isn't a main VFP EXE, that's IIS or one of it's processes or ASP.NET or whatever is used server side to use the COM servers and in web services such EXEs are persistent, usually, Servers are not clients.

So all in all you better program to close and erase files not needed anymore and on top of that may do some manual "garbage collector" deleting temp files following certain name patterns.

Chriss

 

[dbMark]

Thanks for the insight. I do recall this was the server's Temp folder where I went to clear out the old files. I had just been mystified why only certain of the report app's temp DBF/CDX remained there. Maybe I can let it go, it's all in the past now, shortly before I was let go, my employer closed down my site with VFP for another using Java.