Hey Matt. Unfortunately, I've run into similar problems in web development. Frustrating, isn't it? Based on the detective work I've had to do for my own work, here are a few questions/points that might help...

You seem pretty confident about the VFP code. So, following up on your ODBC concerns, could it be the ODBC driver's connection pooling, or lack thereof (or, for that matter, the connection limits of the database itself?) There are several MS knowledge base articles that can help (for instance, http://support.microsoft.com/default.aspx?scid=kb;en-us;164221).

-- Also, are you running these components under COM+/MTS? If so, do you have MTS transactions set on? I've used MTS transactions for SQL Server, and have run into some performance issues that seem to escalate to a point of "hanging" periodically. You need to be awfully careful about setting isolation levels and such if you are using DTC. And, I wouldn't be shocked if there are even more issues using COM+ distributed transactions with Oracle.

-- What happens if you take the components out of MTS? I am not one of the anti-MTS folks, so I am not necessarily recommending this as a production solution, but it will help narrow down the variables.

-- You mentioned that IIS hangs. Are you sure it's IIS and not the app server or the database? In other words, if you have another, very simple ASP page (that doesn't call the database or any VFP component), can you access this page successfully during the "hang"?

-- Have you taken a look at the number of objects created and activated in the MTS component console at the point of the hang? My guess is that they are maxed out (this is not necessarily the issue, but I would be very surprised if they are *not* maxed out, and that might tell us something.

-- Microsoft has a great tool called "Autodump+". It captures everything going on in your system, at the point of a freeze (or whenever, actually). It's free and it's easy to use... but it is really difficult to read and interpret. Nonetheless, we were able to find a few red-flags even without being experts at reading it, and we were able to track down a few errant components, who *always* seemed to locked at the point of system freezes. A little investigation revealed that these components were each indexing cursors to macro-expanded values.... now, this in itself doesn't seem a bad thing, but when we changed it, guess what? No more problem. In other words, autodump helped us isolate a few VFP code issues, on the basis of empirical evidence that we would not have otherwise found because we weren't encountering the same problems on our own servers.

Hope this helps.




>Hi Claude,
>
>I'm not sure what you mean - the problem only seems to exist on the multiprocessor server [which is in Hong Kong]. We can't replicate it here at all.
>
>We also can't step through the code in the debugger - the prg file is built into a com dll. An ASP page then creates the com object, calls a function in it and accepts the return value from it. The com object is then destroyed.
>
>This code all runs without error - the problem only occurs when tested with 200 threads on the web stress tool over a period of 1 hour. Again, this has only happened on a multiprocessor server in Hong Kong.
>
>My concern is that there may, for instance, be a memory leak in the Oracle 9i ODBC driver or a bug in ASP or Windows 2000 which is triggered by the creation and destruction of so many COM objects on the server. However, because there are so many tools being used in this project, I can't really say where the problem lies. We don't get any kind of error message - IIS just stops responding.
>
>I'm convinced that the actual VFP code which I've written isn't the problem [since I would expect the VFP code to error no matter how many processors were involved].
>
>
>Best.
>
>Matt.
>
>>you should be able to test individual elements with the Stress tool. Also you can step thru the VFP mtdll code now with the debugger...
>>>Hi Claude,
>>>
>>>We've made sure to replace the VFP runtime libaries and they definitely match SP5. Do you know if other files are replaced by SP5.
>>>
>>>We've also run the tests here on a single-processor server without problems. I'm not sure how we proceed here because the problems could originate in any of the software we are using - it may not be a VFP problem at all.
>>>
>>>Best.
>>>
>>>Matt,.
>>>
>>>>Matt,
>>>>Important: make sure it's VFP6 SP5 - many vfp mtdll problems fixed with that SP.
>>>>Check out message#627606 from Mike Stewart of Microsoft. He regularly tests VFP mtdlls on a 4 processor machine.
>>>>There's a little about multi-processor with VFP mtdlls here:
>>>>http://www.activevfp.com/dev/dna08.htm
>>>>The MS stress tool is easy to use. you should be able to approximate what they're doing and identify problem areas...