Date:  06/15/2003 11:28:42 PM Msg ID:  001501
From:  FoxWeb Support Thread:  001462
Subject:  Re: Channels taking coffee breaks?
FoxWeb 2.5 will be released in the next few days -- probably later this week.
 
Official support for VFP 8 and a VFP 8-compiled version did not make it in FoxWeb 2.5, but it will be included in an update later this summer.  We have run FoxWeb 2.1 successfully with VFP 8 and several clients have reported running VFP 8 in their production environments, but we have not completed our QA testing so we can't officially support this configuration.  Please note that since we are not including a VFP 8-compiled version of FoxWeb, you will only be able to run it with the Use Run-Time DLL option disabled.
 
There's no feature that will automatically kill channels consuming too much memory, but you can probably add something like this in fw_enter.prg, or fw_exit.prg.  All you need to do is add code that checks memory usage and sets the memory variable FW_Restart to 2.  This undocumented variable will cause a channel to exit (and restart if the Auto-Restart Channels option is enabled) as soon as the current request is completed.  For example, you can use the following code:
IF SYS(1016) > 1000000
M.FW_Restart = 2
ENDIF
 
FoxWeb channels get restarted automatically if they get killed, but you should probably be careful with this, because they may leave temporary files behind and may even cause data corruption if they are killed while they are writing to a local table.
 
I am not sure why you are getting the CGI error you mention, but if you are using FoxWeb with IIS you may want to use the ISAPI extension foxweb.dll instead.  It is faster and less resource intensive than foxweb.exe, because it does not require the spawning of a new process with each request.

FoxWeb Support Team
support@foxweb.com email

Sent by Randy B on 06/13/2003 07:51:42 AM:
When do you expect to release 2.5?
 
How about support for Visual Foxpro 8 ?
 
Also, I wish there was a feature in Foxweb which would automatically kill and restart the channels/VFP processes if they are consuming too much memory.  For some reason, our vfp7 processes (same thing happened with vfp6) will start gobbling up large amounts of memory over time.  Once one or more of them are using hundreds of megs, we start seeing the "can't connect to broker" message or whatever.  We're not sure where the memory leak is.  But if foxweb could kill and restart the processes taking up large amounts of memory, that would make us happy.  Or if you have some suggestions for tracking down the cause of the large memory consumption, that would be nice.  ALL of our scripts talk to a back-end MS-SQL database using the Foxpro =sqlexec() function (which returns data in cursors).
 
By the way, is it "bad" to just KILL one of the vfp7 processes on the
Windows server.  Will foxweb just spawn a new one?
 
While I'm asking questions, any comments on this message which we get a lot (at random):
 
CGI Error - The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:  [BLANK]
 
We're running Foxweb 2.11 on Win2K.
 
Thanks
 
Randy
Magma
 
Sent by FoxWeb Support on 05/27/2003 02:05:03 PM:
Here's the list of changes in version 2.5:
  • AddScriptTimeout can extend timeout from time of call using bFromNow argument.
  • Fixed problem that in rare cases caused channels to be restarted even after AddScriptTimeout and SetScriptTimeout methods were invoked.
  • Resolved FoxWebCtrl Socket Error 10054 and 10053 issue.
    Broker does not write 10054 error when the connection with the channel is broken (usually as a result of a channel restart).
  • Channel re-registers with the broker every 30 seconds, to verify that the broker knows it is available.
  • Added code to reject URLs that contain \..\ sequences (this did not work with most web servers anyway).
  • Error handler handles large memvar dumps (thousands of memvars) gracefully.
  • Error handler uses a more intelligent algorithm to parse and log memvar dump.
  • Channels try to re-connect to broker if they encounter a 1440 error within one minute of startup.
    Added ability to edit FoxWeb Temporary Directory in FoxWeb Control Center.
  • Fixed problem is FWXCompile, which caused it to exit without compiling under certain circumstances.
  • Moved call to set_env at the beginning of www_read to prevent problem when  date format is changed with SET DATE command (for example SET DATE BRITISH).
  • Improved speed of Server.ToString method for VFP 6 and above.
    Response.Write does not translate "%\>" to "%>" any more.
  • Fixed problem that prevented correct error reporting within fw_enter and fw_exit.
  • Fixed problem which caused show_channels to return "No Channels Active" under certain circumstances.
  • Fixed problem which caused show_channels to return incorrect number of pending requests.
  • Auth object can handle single quote characters in userid.

FoxWeb Support Team
support@foxweb.com email

Sent by Robert Thomas on 05/26/2003 09:47:18 PM:
Is there a list of new features / bug fixes for 2.5 yet???
 
Sent by FoxWeb Support on 05/26/2003 11:15:01 AM:
This is a known problem that occurs under certain circumstances on heavily-loaded servers.  The bug has already been fixed and will be released in June as part of FoxWeb 2.5.

FoxWeb Support Team
support@foxweb.com email

Sent by Joe Cosby on 05/25/2003 04:49:31 PM:
I'm running Foxweb 2.11 on Win2k servers
 
I have run into this problem a couple of times since switching from FW1.x to 2.11.  We have multiple channels open, say 4, I go in and check on a machine and it is only showing 1 or 2 channels in the Foxweb Channel Status window.  The others don't show as busy or unresponsive, they just don't show at all.  Restart channels is enabled and FW is configured in the configuration form for 4 channels, they just seem to disappear over time.
 
At first I thought it just wasn't showing all the available channels or something;  to be honest I haven't looked very closely at the 2.x docs since we upgraded, we didn't really need the new features.  Looking at this closer though this definitely affects end users, performance is really dogging when we are down to one channel and have multiple users, not to mention we start hitting frequent timeouts (no channels open).
 
We aren't set up for FWX pages right now, so http://localhost/show_channels.fwx isn't available, I don't know if it would show me anything that the status window doesn't.
 
It seems like I need to set up some kind of maintenance process to step through channels and restart them when they disappear like this.
 
Has anybody run into a similar problem?  Any examples of maintenance processes like that?