Running in com mode on the first load of the com no Output is returned When i refresh the browser it's ok

Not sure but shouldn't happen.

Make sure your error handling is working. I suspect you're getting an error and your error handler is... erroring 😄. That's the most likely scenario for no output (or the request really returns no data).

+++ Rick --

Hello,

My code is error free and run error free with WC 6.21, every code error is logged
I think it has something to do with the load of the COM, one second later everthing is ok But on the first click ( on the browser side ) the message "No output returned" is instantaneous there is no waiting time

Here is the error in wcerrors.txt

2024-10-19 11:17:44.125 - 3464124146916147_80 - *** Com Server ProcessHit Error: Server not available, trying to reload: Le serveur RPC n’est pas disponible. (Exception de HRESULT : 0x800706BA) (800706ba) Time: 0,00ms - /greenshop/fr/processconfig.jaz 2024-10-19 11:17:46.732 - 3464124146916147_80 - No output returned - /greenshop/fr/processconfig.jaz

Tks Marcel

Not sure - I can't duplicate that behavior.

Is it duplicatable? Local development? On your server? How many instances? If you're using many start with a few first then work up (which would isolate a potential load timeout).

A few things to check:

• Make sure you have the latest version (8.1 - check Administration.wc)
  Very early releases of v8.0 had a few small problems and if I recall this was one of them.

• Make sure your server is compiled correctly (Single Use EXE)
  Anything else isn't supported or tested.

• If all else fails: Create a new project to test behavior
  Create a new Web Connection project, compile it to COM and run as a COM server. Same behavior?

+++ Rick ---

Hello, It seems that the WC 8.1 no longer compatible is with the way I work. COM mode work's as described above and file mode doesn't run any more

*** Configuration class for the GreenwebProcess Process class
DEFINE CLASS GreenwebProcessConfig as wwConfig

cHTMLPagePath = "c:\WebConnectionProjects\Greenweb\Web\Greenweb"
cDATAPath = "c:\WebConnectionProjects\Greenweb\data"
cVirtualPath = "/Greenweb/"

ENDDEFINE

The webservers are running with 5 applications (WebShop (.jaz), Blog (.blog), Forum (.frm), Products (.jazz), Data administration *.appl) using same code in "c:\WebConnectionProjects\greenweb\deploy".

Each server as is own directory and web.config in c:\WebConnectionProjects\greenweb\web\serverXX etc ....

When running in file mode a deploy directory is created in the wrong place to report a error, running in COM mode errors are reported in the good place c:\WebConnectionProjects\greenweb\deploy\temp

Here is the error

PHYSICAL_PATH=C%3a%5cWebconnectionprojects%5cGreenWeb%5cweb%5cgreenweb%5ctestpage.sys&QUERY_STRING=&SCRIPT_NAME=%2fgreenweb%2ftestpage.sys&REQUESTID=639863735582_152&DLLVERSION=Web+Connection+Handler+8.1.2+(.NET+Handler)++&WCCONFIG=C%3a%5cWebconnectionprojects%5cGreenWeb%5cweb%5cgreenweb%5cweb.config&ADMIN_PAGE=%2fgreenweb%2fadmin%2fadmin.aspx&APPL_WEB_PATH=http%3a%2f%2flocalhost%2fgreenweb&APPL_MD_PATH=%2fLM%2fW3SVC%2f1%2fROOT%2fgreenweb&APPL_PHYSICAL_PATH=C%3a%5cWebconnectionprojects%5cGreenWeb%5cweb%5cgreenweb%5c&AUTH_TYPE=NTLM&AUTH_USER=DESKTOP-9MVQ9H9%5cMarcel&AUTH_PASSWORD=&LOGON_USER=DESKTOP-9MVQ9H9%5cMarcel&REMOTE_USER=DESKTOP-9MVQ9H9%5cMarcel&CERT_COOKIE=&CERT_FLAGS=&CERT_ISSUER=&CERT_KEYSIZE=&CERT_SECRETKEYSIZE=&CERT_SERIALNUMBER=&CERT_SERVER_ISSUER=&CERT_SERVER_SUBJECT=&CERT_SUBJECT=&CONTENT_LENGTH=0&CONTENT_TYPE=&GATEWAY_INTERFACE=CGI%2f1.1&HTTPS=off&HTTPS_KEYSIZE=&HTTPS_SECRETKEYSIZE=&HTTPS_SERVER_ISSUER=&HTTPS_SERVER_SUBJECT=&INSTANCE_ID=1&INSTANCE_META_PATH=%2fLM%2fW3SVC%2f1&LOCAL_ADDR=127.0.0.1&PATH_INFO=%2fgreenweb%2ftestpage.sys&PATH_TRANSLATED=C%3a%5cWebconnectionprojects%5cGreenWeb%5cweb%5cgreenweb%5ctestpage.sys&REMOTE_ADDR=127.0.0.1&REMOTE_HOST=127.0.0.1&REMOTE_PORT=50872&REQUEST_METHOD=GET&SERVER_NAME=localhost&SERVER_PORT=80&SERVER_PORT_SECURE=0&SERVER_PROTOCOL=HTTP%2f1.1&SERVER_SOFTWARE=Microsoft-IIS%2f10.0&URL=%2fgreenweb%2ftestpage.sys&HTTP_CONNECTION=keep-alive&HTTP_ACCEPT=text%2fhtml%2capplication%2fxhtml%2bxml%2capplication%2fxml%3bq%3d0.9%2cimage%2favif%2cimage%2fwebp%2cimage%2fpng%2cimage%2fsvg%2bxml%2c*%2f*%3bq%3d0.8&HTTP_ACCEPT_ENCODING=gzip%2c+deflate%2c+br%2c+zstd&HTTP_ACCEPT_LANGUAGE=en-US%2cen%3bq%3d0.5&HTTP_COOKIE=GREENSHOP%3d7AZiGtBhY6bing71%3b+_ga_4YTGKTLEXZ%3dGS1.1.1729347418.275.1.1729348621.58.0.0%3b+_ga%3dGA1.1.904273704.1679135213%3b+language%3dfr%3b+_ga_WXPFEFR1S7%3dGS1.1.1729343064.223.1.1729343167.0.0.0%3b+_uetvid%3d865981d0d7ba11ed88298586bca358c1%3b+_clck%3d1cnti9%257C2%257Cfq5%257C0%257C1230%3b+jj_acceptCookies%3dtrue%3b+_gcl_au%3d1.1.1140251554.1723887350%3b+PROFILAGE%3dkhNBVShgVCq79AH6%3b+MARCEL%3dITjdYGReuAwdk0yW%3b+JAZZJUICERS%3dQ9W49j8hkD3yiVcA%3b+_uetsid%3d6b7357408d5511efbf022ffaf6fc087d%3b+_clsk%3d15b8ro9%257C1729348622139%257C5%257C1%257Cw.clarity.ms%252Fcollect&HTTP_HOST=localhost&HTTP_USER_AGENT=Mozilla%2f5.0+(Windows+NT+10.0%3b+Win64%3b+x64%3b+rv%3a131.0)+Gecko%2f20100101+Firefox%2f131.0&HTTP_UPGRADE_INSECURE_REQUESTS=1&HTTP_SEC_FETCH_DEST=document&HTTP_SEC_FETCH_MODE=navigate&HTTP_SEC_FETCH_SITE=none&HTTP_SEC_FETCH_USER=%3f1&HTTP_PRIORITY=u%3d0%2c+i&Output+File=C%3a%5cWebconnectionprojects%5cGreenWeb%5cweb%5cdeploy%5ctemp%5cWC_639863735582_152.out& #@$ FORM VARIABLES $@#

It's seems the location of web.config don't read the cHTMLPagePath property of the config file ( edit config is disabled )

Tks Marcel

Yes I do the test with a new project to test the behavior

The are also small bugs in the web.config file when you ask to create a project with multiples extensions

Tks Marcel

The new project structure is very specific to a single server/site setup. It's possible to use it with multiple or multi-tenant sites, but not out of the box. The project will create it's own structure and if you want to use this auto-configured environment you have to stick to the default format it creates. If you move stuff around things are no longer automatic and will break unless you fix the configuration to match the changes.

What I'm asking you to do is not try to port your project - I'm asking you to create a new empty project, run it and see if that works to verify whether there is a real problem or something that is introduced due to your specific setup and configuration.

+++ Rick ---

The webservers are running with 5 applications (WebShop (.jaz), Blog (.blog), Forum (.frm), Products (.jazz), Data administration *.appl) using same code in "c:\WebConnectionProjects\greenweb\deploy".

That's a very unconventional setup and that's not supported out of box. It can work but you have to configure for it.

Not sure what you mean by *'The webservers are running with 5 applications (WebShop (.jaz), Blog (.blog), Forum (.frm), Products (.jazz), Data administration .appl) using same code in "c:\WebConnectionProjects\greenweb\deploy".' If you're running 5 applications as COM off the same EXE/codebased, doing this with COM is super complicated and nothing in that process has really changed over the years.

cHtmlPagePath is a fallback value that is only used if the base path cannot be determined by what the Web server provides. It was never used verbatim for determining anything beyond the fallback value or for your own use in your application code. Web Connection uses the APPL_PHYSICAL_PATH server variable to determine the site base path based on the incoming request.

There's only one place in the Web Connection codebase where this path is used:

* wwRequest::GetApplicationPath
FUNCTION GetApplicationPath()

IF EMPTY(this.cApplicationPath)
    *** IIS provides the Application base path
	this.cApplicationPath = ADDBS( THIS.ServerVariables("APPL_PHYSICAL_PATH") )	   
	
	*** if not use app.ini setting variable from process
	IF EMPTY(this.cApplicationPath) AND TYPE("Process.oConfig") = "O"
		this.cApplicationPath = ADDBS(Process.oConfig.cHtmlPagePath)
	ENDIF
ENDIF 
RETURN this.cApplicationPath
ENDFUNC

Which is used for root folder lookups and Process.ResolvePath() and ~ physical path resolution.

All other uses are application specific and that's what the value is there for, really. The value was primarily created for non-IIS and very old IIS servers that don't return the base path with the application.

This hasn't changed for a very long time and certainly not since v6 (I think the last time this behavior changed was likely in v4).

+++ Rick ---

That's a very unconventional setup and that's not supported out of box. It can work but you have to configure for it.

It was your idea 😃

					CASE lcExtension == "JAZ"
						DO Store_process WITH THIS

					CASE lcExtension == "JAZZ"
						DO Products_process WITH THIS

					CASE lcExtension == "APPL"
						DO Application_process WITH THIS

		      		CASE lcExtension == "BLOG"
		         		DO Blog_Process with THIS

					CASE lcExtension == "FRM"
						DO Forum_Process WITH THIS

If you're running 5 applications as COM off the same EXE/codebased

Each server has its own exe ( and project file ) that use the same code only the startup.prg is different I only add one parameter on your code

DO GreenWebMain.prg  WITH lcAction, lvParm1, lvParm2, "GreenWebShopsServer"

Create a new project to test behavior

That's what I do. The only thing to do to reproduce the error's is to move the Html files from

web\*.html,*.jazz etc...     to      web\myserver\*.*

Of course you have to change web.config etc.. data for the new path

Tks

Marcel

Each server has its own exe ( and project file ) that use the same code only the startup.prg is different I only add one parameter on your code

Ah ok... yeah that's fine. That's just not what the typical user will come up with in this situation. Sharing a single EXE (and COM ids) for multiple apps is complicated - I don't recall this conversation, but I've helped a couple of customers set this up and it's no fun. It's very easy to screw something up in the process - the only good solution is what you're doing: Separate projects with separate COM IDs separately compiled and deployed as essentially completely separate apps even though they effectively run the same code base.

That's what I do. The only thing to do to reproduce the error's is to move the Html files from

Not sure I understand. You're saying using the stock configuration there's no problem (ie. directly in the /web folder). But it breaks if you map to a sub-folder and then it breaks on the first request?

Can you log your inbound folder configuration in wwProcess::OnInit()?

Log out:

• THIS.oRequest.GetPhysicalPath()
• THIS.oRequest.GetApplicationPath()

And what are you doing for your first request exactly? Response.ExpandScript/Template, manual output? And what exactly are you doing for the configuration?

Are all of these EXEs running in their own Web application folders/virtuals?

+++ Rick ---

Hello,

I don't recall this conversation

You are right we don't have a conversation about multiserver on same code, you idea is the multiscript map. Multiserver on same code is my own work

Can you log your inbound folder configuration in wwProcess::OnInit()?

Here is my code, each MyServer.exe has is own configuration MyServer.ini

	PROTECTED FUNCTION OnInit

		THIS.oConfig = CREATEOBJECT(THIS.cConfig)
		THIS.cAppIniFile = ADDBS(THIS.cAppStartPath) + ALLTRIM(THIS.cAppName) + ".ini"
		
		WITH THIS.oConfig
			.cRootPath = STRTRAN(ADDBS(LOWER(THIS.cAppStartPath)),"deploy\","")
			.cSystemFilesDataPath = THIS.oConfig.cRootPath + "SystemData\"
			.cFileName = THIS.cAppIniFile
		ENDWITH 
		
	ENDFUNC

Not sure I understand. You're saying using the stock configuration there's no problem (ie. directly in the /web folder). But it breaks if you map to a sub-folder and then it breaks on the first request?

Yes first request in COM mode breaks on the first request and then it works. It does not work in file mode. Maybe I miss something when I updated the config files manually it would be a good news if it run on a web subfolder on your side

And what are you doing for your first request exactly? Response.ExpandScript/Template, manual output?

RESPONS.ExpandTemplate()

Are all of these EXEs running in their own Web application folders/virtuals?

Yes

I also recently found a Bug in merge text ( after using it for 20 years... ). It loops when passing a variable other than a character.

Tks

Marcel

If it doesn't work in file mode you should be able to step through and see what's happening.

I have no idea because I can't duplicate your scenario (since I still don't understand what you're actually doing). If you create separate script maps the scriptmaps work for the entirety of the virtual/application.

You still haven't answered my question. If you create a new project and run as is (without any of your path customization) does that work on first hit? IOW - no errors? If it does then the issue is related to how you are routing requests or setting up the paths.

If it happens in file mode you should be able to step through with the debugger and see where the code gets the blank result. You can set breakpoints in your application code to see if those requests are reached in the first place. If not you'll have to debug in wwProcess::Process(), wwProcess::RouteRequest() and wwProcess::CompleteResponse().

+++ Rick --

I do a new setup again and it work's by moving all the web directory contents to a web subdirectory simply by updating the deploy path in Web.config

I'm going to integrate my code in a more progressive way to understand what didn't work.

Thank you for your help !

Marcel

Oh good! 😄

+++ Rick ---

I understand better what was happening

There have probably been changes in the wwserver class

SET DEFAULT TO xxxx

MODIFY PROJECT xxxxx NOWAIT -> and then do xxxx from the project don't work

GetAppStartPath() in wwserver.prg returns the path of the startup directory, so a stock project is ok when started with your shortcut but not with the config.fpw in the default foxpro directory

This was not the case in the original wwserver.vcx

Marcel

Nah GetApplicationPath() was always used. But what did change is how OnInit() and OnLoad() sequence and so any custom code might have had for custom path behavior acts differently.

The OnInit() method in your server is meant exactly for this scenario. When the method is fired GetApplicationPath() has fired and you can override the startup path in OnInit(). In your case specifically you'd want to explicitly set cApplicationPath and SET DEFAULT TO to your custom paths in OnInit().

FYI, wwServer does server initiallization before OnInit(), so you can override this behavior in that method:

*** Configuration based on User settings

*** Read the App Base Path (from EXE filename on OLE Servers)
*** This value can be overridden in SetServerEnvironment
THIS.cappstartpath = THIS.GetAppStartPath()

*** Add the basic path to the startup application

*** All Exe's can SET DEFAULT TO - DLLs cannot
IF lnStartMode # 3 AND lnStartMode # 5 && COM EXE
   SET DEFAULT TO (THIS.cappstartpath)
ELSE
   DO PATH WITH (THIS.cappstartpath)
ENDIF


*** Set default server names - default to this class for the INI file
*** and section within it
THIS.cAppName = THIS.CLASS

IF ENDSWITH(this.cAppName,"server",.T.)
   this.cAppName = SUBSTR(this.cAppName,1,LEN(THIS.cAppName)-6)
ENDIF
THIS.cAppIniFile = THIS.cappstartpath + THIS.cAppName + ".ini"

*** Create a global resource store
this.oResources  = CREATEOBJECT([WWC_WWNAMEVALUECOLLECTION])

*** Create a permanent instance of the Cache class and attach
THIS.oCache = CREATEOBJECT([WWC_CACHE])

*** THIS FIRES `OnInit()` eventually
IF !THIS.OnInitInternal()
   IF EMPTY(this.cErrorMsg)
      THIS.cErrorMsg = "OnInit Aborted loading of server."
   ENDIF
   RETURN .F.
ENDIF

All other initialization - including anything that relies on the current environment path (SET DEFAULT) and cApplicationPath then happens after OnInit() has fired and uses those settings as if WWWC had started out of that folder.

Essentially OnInit() is meant to override any Initialization settings that affect how the server starts up and where it looks for things. Typically there are very few things that need this and the most common is customizing the startup path.

+++ Rick ---