Web Connection
Invalid Path or Filename??
Gravatar is a globally recognized avatar based on your email address. Invalid Path or Filename??
  Stein Goering
  All
  Jan 13, 2024 @ 11:20am

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

Gravatar is a globally recognized avatar based on your email address. re: Invalid Path or Filename??
  Rick Strahl
  Stein Goering
  Jan 14, 2024 @ 06:04pm

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 ---

Gravatar is a globally recognized avatar based on your email address. re: Invalid Path or Filename??
  Stein Goering
  Rick Strahl
  Feb 11, 2024 @ 09:00pm

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

Gravatar is a globally recognized avatar based on your email address. re: Invalid Path or Filename??
  Matthew Olson
  Stein Goering
  Mar 20, 2024 @ 04:33am

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

Gravatar is a globally recognized avatar based on your email address. re: Invalid Path or Filename??
  Rick Strahl
  Matthew Olson
  Mar 20, 2024 @ 01:42pm

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 ---

Gravatar is a globally recognized avatar based on your email address. re: Invalid Path or Filename??
  Stein Goering
  Rick Strahl
  Mar 21, 2024 @ 10:29am

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.

Gravatar is a globally recognized avatar based on your email address. re: Invalid Path or Filename??
  Rick Strahl
  Stein Goering
  Mar 21, 2024 @ 03:42pm

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 ---

Gravatar is a globally recognized avatar based on your email address. re: Invalid Path or Filename??
  Matthew Olson
  Rick Strahl
  May 14, 2024 @ 10:43am

Update: I was able to set up a server with our application and duplicate what some of our users were reporting on there. This was then the baseline to work from.

Not know what else to do, I put all SET PROCEDURE calls in an IF to be sure they actually needed to be called. I had a typo in one of my IFs and wouldn't you know it, that was the one that failed within a day or so. After fixing that one, I've not had any issues since. The IF statement is of the form:

IF ATC([wwAPI],SET("Procedure"))=0

I'm not sure if the extraneous SET PROCEDURE calls were what were corrupting things or getting lost in everything else, but I'm at least ready to put something into production for these people to try. Hopefully, they can see the same results I am getting.

Anyway, if you don't hear from me, assume the above as the fix.

Thanks, Matthew

Gravatar is a globally recognized avatar based on your email address. re: Invalid Path or Filename??
  Rick Strahl
  Matthew Olson
  May 14, 2024 @ 10:59am

If you had a typo in there that would mean that library wouldn't get loaded, so that would explain the failure.

FWIW, in theory there should be no problem with doing a SET PROCEDURE with an already loaded library - FoxPro should be smart enough to not try to reload it, and if it loaded it from the EXE the first time, it should load it from there again. The main issue that could come in is if it's a 'dynamically' loaded reference that hardcodes the path (such in the case of a WCF Page).

To avoid any loading overhead is why I recommend loading all dependencies on startup, using a loader of some sort that loads everything. Also, ideally PRG files declare their dependencies at the top with their own SET PROCEDURE TO and SET CLASSLIB TO dependencies so you each class/component can load all its dependencies with DO MyPrgFile.prg

+++ Rick ---

© 1996-2024