Hi Claude,

>Just a note on mtdlls crashing the web server or getting C5s - it doesn't happen, at least for the past 4 years it hasn't on mine on any client web servers we've done. The reason it doesn't is that it's running in pooled isolation or high isolation protection. Add to this the use of COMRETURNERROR and all of your web errors are dealt with in a very behaved way, not crashing the web server at all or even the web application.
>VFP mtdlls are definitely more light-weight and should scale better than having 3-4 VFP exes running in the background. And STAs are actually multi-threading, not simulating MT like running several .exes in the background. I'm not claiming vfp mtdll technology is perfect, only an improvement...

Ok, here's a test you can try to see what happens exactly:

PROCEDURE CrashGPF

DECLARE GetSystemTime ;
   IN WIN32API ;
   STRING @
   
lcText=" "
lcText = GetSystemTime(@lcText) 

RETURN "Made it through"
ENDFUNC

Then call this from an ASP page.

< %
set oVFP = CREATEOBJECT("aspdemos.asptools")
oVFP.CrashGpf()
Response.Write("Done Waiting...")
% >

Hit this page a few times. The first time you get a minor error, followed by a pretty hard failure message. After 3 or more hits ASP detects the full C5 and blocks access to the component. Any further access will result in an error message or in some cases in the request simply hanging (especially when running the component under COM+).

This is obviously a concocted scenario to make VFP fail on purpose and it's a pretty severe error (although small in terms of corrupted memory). VFP crashes are pretty rare and getting ever rarer with newer versions especially VFP 9. But VFP crashes - especially when under load. These are failures that are next to impossible to track and rarely are repeatable.

But this is not a far fetched scenario. I've been dealing with VFP crashing (in ASP, WWWC or otherwise) for many years. I've spent quite a bit of time early on in Web Connection development to deal with this, and you know why? Because customers understandably were not happy if VFP crashed that the app would stop running. It doesn't matter whether it's their code, WWWC or Visual FoxPro's innards. They blamed WW and my tools, regardless of where it comes from. They want an app that runs and more importantly STAYS UP and running. In WWWC, because it knows with what it's dealing with exceptions are handled and objects reloaded if it happens. Will this handle all problems with C5's? Nope - obviously if data corrupts or data corruption is the problem in the first place erros will continue, but it handles the 'odd unexplainable, unreproducible' VFP crash that happens once every few days or wahtever... It also deals with things like time out processes that are stuck in endless loops or other programmatic erros that cause an app to get stuck.

If you think this isn't a big issue, then we have to disagree. This will not fly with anybody trying to build an enterprise application. The real sad part is that these kind of problems won't be found until an app goes live because until then few people bother to test their apps under load for extended periods.

Nothing is perfect. Maybe good enough, is indeed good enough...

This problem isn't unique to VFP either, its a problem with ASP and COM (not sure exactly what happens in ASP.NET but I suspect it's not that different since hte issue is that hte object is loaded into the hosting process).