One of our customers is reporting a very strange behavior pattern. They launch our app - things work fine for an hour or so - then certain pages start to fail. The error that consistently comes up is "Invalid path or file name" but it is triggered by different commands depending on the method.

 cClassLib = [awBusinessObject.prg]
 loProduct = NEWOBJECT(cClassName,cClassLib,Server.oSys.cExe)
      
SET PROCEDURE TO wwDotnetBridge ADDITIVE

SET PROCEDURE TO wwAPI ADDITIVE

In each case it is attempting to access a PRG based class library - but all of the PRGs in question should be compiled into the exe - how can they not be located?

Not to mention that all of these methods work initially - as noted the problems only show up after an hour or so of activity. If we reset IIS, everything will start working again for a while. I would also note that we have the identical exe running on other customer sites with no evidence of this problem.

The last thing we did was switch them from Com to File mode - at last report, they had been running for several hours without seeing any failures. So was the problem somehow tied to Com operation?

If anyone can shed any light on this, I'd appreciate your suggestions.

--sg

That sounds like potential COM Server corruption. You might want to check the Web Connection server logs and see what errors are being thrown prior to the failures or as they happen.

Especially if running ISAPI many COM failures (ie. servers getting force released frequently) can end up causing corrupted instantiations of objects. Less of a problem with .NET module, but even there can be a problem as that is a COM system issue. Bottom line - make sure servers are not getting force released all the time.

+++ Rick ---

Following up on this in case anyone is interested... [And if you're really interested, note correction below...]

They were running under ISAPI so one of the first things we did was put them on .NET but unfortunately that did not resolve the issue.

We checked various error logs but were unable to come up with anything conclusive. *Finally just spun up a new server instance, installed our app from scratch and loaded the data from backup. *

OK, they were considering that option but it turns out they first tried just switching to File Mode. That appears to have solved the problem as things have been running smoothly ever since. Never did figure out what the COM issue was, but given how robust File Mode is under .NET, they might as well just stick with it.

--sg

I'm investigating this issue with Stein. I was able to track some of the webconnect error messages to this entry: __WebPageList.Filename Not sure how that entry is fine for a while and then goes caput (Invalid Path or File Name).

Also of note, this is only happening to customers and test instances where they are running multiple script maps with multiple database locations. From what I can tell, the above cursor entry is for the executable running, so I'm not sure why this is the factor that is corrupting things.

Any ideas?

Thanks, Matthew

This cursor is from the Web Control Framework that keeps track of compiled program files. It looks to me that this cursor is getting corrupted, but not sure how that happens.

If the cursor is closed accidentally it'll just get recreated so that can't be the problem. And there's only one place where this table gets written to in webPageParser.prg.

Can you tell what the issue is actually? Is the table corrupt? Is it pointing at a file that is no longer there? Is the FXP or PRG it's trying to run corrupt (if compiled)?

You do have to be careful with updating files into a live running application - if you update these Web Control files, you need to make sure the app gets restarted so that cursor gets recreated with new info and the cached FXPs are recognized by all the executing instances.

+++ Rick ---

This cursor is from the Web Control Framework that keeps track of compiled program files.

That might explain why we're getting these invalid path errors on SET PROCEDURE calls that point to PRGs that should be compiled into the main exe.

FWIW, this is no longer limited to a single customer site - we've seen it happen in mulitple cases. After upgrading a client to our latest version, if they're running in COM, it will work initially but they'll start getting the errors at some point. The solution in each case has been to switch the to File Mode.

We have a well-established upgrade procedure that involves stopping IIS and unloading all servers so I do not think that is the issue. Evidently the problem is triggered by something we did to our code prior to the last release, but we have no clue what that might be. We definitely did not mess around with anything at the webPageParser level. We thought it might be just a glitch in the compiled exe, but we've since rebuilt and recompiled the app after upgrading to WC 7.40. The issue persists with the new exe.

If the PRGs are compiled in then there shouldn't be any files on disk to match them at the deployed site - they'll just be found from the exe.

However I would make sure that the files are not in the folder when they are also compiled in - my guess they are and the difference between what's compiled and possible external files might be the problem that you see.

Said another way: You don't what to have both compiled and loose PRG/FXP files. One or the other.

+++ Rick ---