View Complete Thread | FoxWeb Forum Home
Search:
Date:    Msg ID:   
From:    Thread:   
Subject:   
It's true that the statement that "the Channel Stopped Responding error means that the channel exited before script execution was completed" is incorrect.  The correct answer is that the error means that the channel exited (was stopped, killed, crashed, etc.) before it finished sending all output data back to the browser.
 
First some background information on the data flow between the various FoxWeb components:
  • A Request is received by Web server
  • If the request is calling a FoxWeb script, it is passed on to the FoxWeb Web module (either a new foxweb.dll thread, or new foxweb.exe process).
  • The Web module asks the FoxWeb Broker for a free channel.
  • The FoxWeb Broker provides the address of the next free channel to the Web module.
  • The Web module contacts channel and passes request to it.
  • The Channel executes the requested script and starts sending data back to the browser (via Web module and Web server).  Data gets sent back either while the script is executing (if Response.Buffer = .F., or Response.Flush is called), or after the script is completely done executing (if Response.Buffer = .T.).
  • As soon as the channel is done executing the script, (but possibly while it's still sending data to the browser), it lets the FoxWeb Broker know that it is available to process another request.
What this means, is that a channel could be executing a script, while still sending data that was served by a previous request (or possibly multiple previous requests).  The maximum number of concurrent requests, for which a channel can be sending data at any time is five.  If this limit is reached, then the channel does not free itself up until data for at least one of the previous requests is transferred in its entirety.
 
The reason for allowing channels to execute scripts before they are done sending data for previous requests is that it makes it less likely for a user with a slow connection to lock a channel while the output data crawls back to his/her browser.  Channels are freed up as soon as they are done executing the requested script -- not when they are finally done sending data to the browser.
 
This works great, but it can cause problems such as what you are experiencing.  In particular, a script error, or script timeout can reset a channel that is still sending data for a previous request, causing the "FoxWeb Channel Stopped Responding" error to appear for all users that are still receiving data from the same channel.  There are a couple of measures you can take to prevent this problem:
  1. First of all determine whether the channel reset is occurring primarily because of script errors, or timeouts.  Script errors are listed in the FoxWeb Error Log, while timeouts are listed in fwstart.log (Restarting Channel X).
  2. If necessary (see #1), eliminate all code that may cause FoxPro errors in your scripts.  Simply go through your error log and fix all problems.
  3. If necessary (see #1), make sure that your script timeout value is set so that channels don't time out while serving scripts.  The timeout value exists, so that channels don't hang when script code gets suspended.  One example would be a script that contains a WAIT, or MESSAGEBOX command.  Another example would be a script that tries to open, or use a non-existent table, which would cause the Open File dialog box to pop up, halting program execution.  The timeout value should be set so that scripts don't time out while executing legitimate code.  If a particular script requires more time than other scripts, then use the Server.AddScriptTimeout method to increase the timeout allowed for this particular script.

We will also look into a couple of changes in version 3:

  1. We will consider not completely resetting channels when a script error occurs.  Currently the whole VFP environment is reset on each script error.  This is done to make sure that the error was not caused by a damaged FoxPro environment.  One possibility would be to reset everything except the control that is responsible for sending data back to the Web module.  This will allow data from previous requests to continue flowing back to the browser.
  2. We will change the way channels are assigned.  If a channel is still sending data for a previous request, it will be given lower priority than one that is completely free.

FoxWeb Support Team
support@foxweb.com email

Sent by Alexey Kouznetsov on 12/08/2003 05:14:12 AM:
Hello!
 
We reported this problem half year ago... We still have this problem after 2.6 upgrade, this return the error AFTER last line in our program exectred, in random place at the web page. This happened at random place of page, and more often on loaded server with lot of requests with big pages (200 KB or more), but may appear on any other size page.
 
Also we reported: If we try to download a file using an example code (Examples/Download.fwx) for download to low speed clients it will never finish. If we check the downloaded file, we will see FoxWeb stopped respond message at end of the file. and this is long after last string of the code executed. it looks like next request came to same channel and overwrite something.
 
/Alexey
 
Sent by FoxWeb Support on 10/31/2003 12:04:36 PM:
The "FoxWeb Channel Stopped Responding" message means that a channel process was exited before it was finished with script execution.  For example, you can cause this error by including a QUIT command in one of your scripts.
 
It is not clear why such a problem would be happening on your server.  It is possible that VFP is crashing, or it is possible that one or more of your scripts contain one of the illegal command listed in the FoxWeb documentation.