Rick,

In the past month my vultr WWWC server starting throwing com errors

The following ole error occurred: WC Server instance not found (CoMarshalInterThreadInterfaceInStream). Err code = 800706be: The remote procedure call failed.

I refresh a few times and all is fine.

Any suggestions?

That's a COM corruption error most likely happening when running with the ISAPI handler, right? Usually when I've seen this, this happens if there are problems with the application and servers have been stopped and restarted (or crashed and restarted) very frequently during the life time of the application pool.

Basically this is a fatal failure that likely will result in the application pool getting restarted (that's why it works after a couple refreshes I'm betting).

This problem is also worse with ISAPI (which does 'manual' COM marshalling in C++ code,) vs the .NET Module (which uses the Microsoft hardened .NET COM APIs and doesn't marshal COM objects over threads as they are pinned on a stationary thread).

I don't have a solution for this, other than making sure that your servers don't crash, or setting an occasional recycle time on your application pool to force it to refresh.

Also more recent versions of Windows Server 2016 and 2019 do a better job of this than older versions, especially 2008 which had lots of COM memory and marshalling problems.

+++ Rick ---

Do you think this has anything to do with the fact that the VULTR servers are virtualized (it is 2012 running incidentally)? I have had a 2008 R2 running for 8+ years and I never see this issue (same software, same config, etc).

Do you think this has anything to do with the fact that the VULTR servers are virtualized (it is 2012 running incidentally)? I have had a 2008 R2 running for 8+ years and I never see this issue (same software, same config, etc).

No. But if you are running with ISAPI you might want to think about switching to the .NET Module.

Look in your error logs - I wouldn't be surprised if you have a number of failures for server unloads.

+++ Rick ---

Rick as you suspected, lots of different errors in wcerrors.

RPC Server Unavailable due to thread timeout WC Server Unavailable. Attempting to reload Web Connection Request timed out RPC Server Unavailable (Invoke): Attempting to Reload Server COM Server Timed out - Next line releases

The pages that are failing are typically pages that use httpget() to call a third party service.

Is there some graceful way to set a timeout in the framework or do you have a different suggestion?

Yeah - so you're likely timing out Web Connection requests which causes the COM servers to be killed explicitly (without shutting down through proper COM release) which eventually ends up corrupting the COM system which allocates a limited amounts of slots for STA components. When it runs out of slots - that's when the errors start due to stream not available etc. It takes quite a few failures before this becomes a problem, but it does eventually become a problem if the Application Pool is not recycled before it does.

So - you'll want to make sure that you have requests that take longer than your configured Web Connection request timeout. If you're making wwHttp service calls there's a timeout property on wwHttp that you can set. If you're calling remote APIs you shouldn't have anything that takes more than a few seconds, so if you're waiting more than 10 seconds you should just consider it failed.

+++ Rick ---

Rick,

Been having lots of com errors again and I revisited this message from a google search. I just realized I ignored your comment about using the .net handler. If you recall my app is a multi tenant ecommerce app. I currently have isapi powering all tenants using a single wc.dll and there tends to be anywhere from 5-10 exe's running as a result. Is my app a candidate to use the .net dll ?

MB

Yes the .NET Module will help with this as there's no COM Marshalling in the .NET code base (everything runs on dedicated separate threads).

But the module introduces other issues that I think in your case were significant - you can't share a single Web Connection server instance across multiple virtuals/sites. Each site requires its own set of servers with the .NET module. If I recall we looked at your setup and decided that the way it was designed there wasn't a way to make that work.

+++ Rick ---

I re-read your docs a few times regarding this topic because I am wondering if I am getting stuck on some of your terminology. For example, the use of the word 'server' can be misinterpreted. Just to be clear, my WWWC app is a single exe and contains the multi tenant setup within it. I have a table named wws_stores that houses one record for each 'site' aka 'store' on the server. When a hit comes into my app I read in the url, navigate to the 'tenant', update my store object and then read the page and its querystring and process as usual.

So, if I use the .net module, it seems I need to have all tenants living inside of a single 'website'. Each tenant could use a shared domain or its own. I think we are good to go there. The only negative here is that if the client wants to use something OTHER than my app, then i expose the other tenants to that setup potentially.

I think I am approaching the 'have to test it' phase. Seems like we have a winner.

Does the .net version fire up as many exe's as I setup in the wc.ini ?

So, if I use the .net module, it seems I need to have all tenants living inside of a single 'website'. Each tenant could use a shared domain or its own. I think we are good to go there. The only negative here is that if the client wants to use something OTHER than my app, then i expose the other tenants to that setup potentially.

No I don't think this works.

Each domain will be its own Web Site or Virtual root and so will have its own set of servers. If you have 20 sites and each site is configured with 2 Web Connection server instances, you'll be running 40 servers for all those sites. For a lot of sites that scenario is not possible. If your tenants are completely unique domains there's no way around that.

If your tenants are all using the same domain, but separate by sub-domain (site1.domain.com, site2.domain.com) then that works because all those sub-domains are just separate bindings to the same IIS domain and those can run a single Web Connection set of servers.

Basically if you create a new Web Site or Application (virtual) it's a completely separate application. Even if you share the AppDomain, as far as .NET concerned the applications are completely separate, which means they need a separate set of servers.

FWIW, it may not be a huge issue to have every application have its own set of servers running - these days of machines of even just 16gb of memory you can fit a lot of FoxPro applications into memory. But managing that many separate server instances all controlled by individual applications is problematic - the only way to do mainteance on those would be to shut IIS down.

+++ Rick ---

Rick,

I wanted to mention something that might help explain some stuff to either one of us. I have an old 2008 R2 server running my same app for over 10 years. I update it with new prg's of yours and dll's every six months or so. This is a dedicated bare metal server at Rackspace. This server does not have any issues like the ones I describe in this thread. The servers that have issues seem to be the ones I spin up at VULTR.

I know you said you dont think the virtualized environment has any issues with WWWC, but maybe this is just a file permissions issue or maybe because the same 'cloned servers' are sharing network names in the same network or something. Maybe I am reaching, but I seem to be having same issues with the app pools conking out, or the wwwc exe crashing.

I often need to re-register the exe on the same that is having the trouble after i terminate the exe's (they get hung).

Again it sure seems like its permissions.

So, can you confirm which permissions the app should have to function normally in com? Should it be IUSR or my 'custom' user that is an admin?

Too broad of a question...

Permissions depend on what you need to do.

If everything is local on the server and you don't need network permissions then you can use SYSTEM which will be the highest permission level account to see if that works.

Don't use DCOMCNFG if you can help it - just set permissions on the Application Pool and then have an account (System/Administrator/Network Service) that has rights to launch the COM components and adjust permissions accordingly. With SYSTEM/Administrator you shouldn't have to adjust any permissions, but obviously not very secure if there's a breach.

+++ Rick ---

I am thinking this may have been the 'permissions' issue I was referring to. The sites were set to IUSR and IUSR does not always have the correct rights - for example creating a file or a temp file.