Date:  09/15/2011 01:33:53 PM Msg ID:  004337
From:  FoxWeb Support Thread:  004329
Subject:  Re: FW channel crashing script
From your past few messages there are a couple of things that absolutely make no sense, based on my knowledge of how FoxWeb works:
 
  • You said that when you stop FoxWeb all VFP processes exit, but when it's running you are seeing twice the number of processes as you have channels. Can you please confirm this? Can you replicate it by a) verifying that you have the extra processes initially, b) stopping FoxWeb and verifying that all VFP processes are gone, and c) restarting FoxWeb and verifying that the extra processes are back? How long does it take for the extra processes to appear?

  • You mentioned that a single request freezes all channels. This is simply impossible. There is no way that a single request can change the status of more than one channel from Ready to Busy. Some logging may be in order. You can start by examining your web server's log to see if other requests have arrived around the same time as the request for the rogue script. If this does not help, you can install additional logging in fw_enter.prg. Just add some code that writes a record in a log table (don't forget to deal with multi-channel file locking issues, otherwise you would be creating a new problem). 
 
Do you not have a way to replicate the problem? If you can, you could try debugging the script, using one of the techniques listed in the Debugging FoxWeb Scripts page of the documentation (http://foxweb.com/document/Debug.htm). 
 
Regarding your upgrade question, you could try installing a trial of version 4.5 and run it with the VFP run-time DLL (or VFP 9 if you have it), but I seriously doubt it will help with this particular problem.
 
FoxWeb Support Team
support@foxweb.com email
Sent by Jeff Grippe on 09/15/2011 10:21:09 AM:
My timeouts are very long because we have some large uploads.
 
Our script timeout is 999 and our session timeout is 120 min.
 
We do sometimes get timeouts. They are recorded in FWStart. There are no references to the script that is causing me a problem in FWStart.
 
When I restart FW, I look at the task manager to make sure that all of the VFP processes have completed.
 
What do you think of the idea of moving From FW 3.0 to the current version and from VFP 7 to VFP 9?
Sent by FoxWeb Support on 09/14/2011 04:49:11 PM:
I realize that after restarting channels, you still see 10 processes, but what about the period between when you stop FoxWeb and then start it again? Do the 5 processes remain? Have you tried killing them manually before restarting? It's possible that they are orphans from a previous session.
 
Also, you did not mention whether you tried looking at channel windows while the channels are locked.
 
By the way, what's your channel timeout? FoxWeb should be restarting channels when they take too long to respond and this would be evident in the log.
FoxWeb Support Team
support@foxweb.com email
Sent by Jeff Grippe on 09/14/2011 03:46:09 PM:
Here are the answers to your questions:
 
1. I was doing the test myself and I did not press the refresh button. I was only because I went to the server to try to see what was happening that I noticed that it did eventually finish. The single script did in fact block all the channels (according to the channel status window).
 
2. Immediately when I restart FW, I see 10 VFP processes in the task manager. I only see 5 on the task bar but I see 10 in task manager.
 
3. FWStart.log did not reveal anything. I'll email it but I don't think you'll find anything about this script there.
 
You can see channel after channel go busy when the script execute once FW has ceased to respond correctly to this script. After I restart FW, the script doesn't effect more than one channel and it returns result to the browser in about 1-2 seconds. When the problem is happening, it take many minutes for this script to return results to the browser.
 
Thanks,
Jeff