View Complete Thread | FoxWeb Forum Home
Search:
Date:    Msg ID:   
From:    Thread:   
Subject:   
Based on our internal tests FoxWeb deals with high server load better than versions 2.5/2.6, which in turn are much better than previous versions.  It is not clear to us why you are getting better performance with version 2.6.
 
Here are the responses to the 3 unanswered questions:
  1. It is not normal for FoxWeb to kill a channel that has not executed fw_enter.prg.  Again, is this related to 2.6, or 3.0?
  2. I can't reproduce the problem with the missing "Restarting" log entries.  It rings a bell, but I think I saw this problem in older versions.  Do you know if these entries were created by FoxWeb 3, or 2.6?  In any case, if the channels were restarted properly, you don't need to worry about it.
  3. It's normal for fw_enter to run without running fw_exit.  It is either caused by channels timing out and getting killed, or even script errors.  After a script error occurs and gets logged, FoxWeb resets the channel and does not run fw_exit.prg.
Regarding the "Error 9" log entries, I notice that FoxWeb was not restarted since they first appeared.  Please restart it, or even better, try re-booting the server.
 

FoxWeb Support Team
support@foxweb.com email

Sent by James Williams on 04/19/2005 05:44:02 AM:
We have now moved back to Foxweb 2.6. This has alleviated the slowing down of scripts, it seems that foxweb 2.6 is dealing with proccessing of multipule scripts better. We ran a few tests to see some speed differences between the two versions.
 
Under Foxweb 3
While running the test that you sent we where able to get one refresh of another script in.
 
Under fosweb 2.6
While running the test that you sent we where able to get three refreshes of another script in.
 
Even though the slowing of the script occured it was acceptable.
 
We will be getting a new dual xeon server in the next few weeks i hope that the new processing and disk access power sorts this out and we can go back to foxweb 3. But does this show that foxweb 3 has more overheads then 2.6 (therefor slower).
 
These Points are repeated because they have not been answered
1. I mentioned that i put an insert statement into the fw_start.prg to log all script execution, but have found that i am getting "killed channels" but with no log of the script starting.
 
2. If you look at the log there are killed channels but with no restarts.
 
3. If you run fwadmin.fwx the fw_start.prg runs but the fw_exit.prg does not.
 
We have started getting these error in the last week
Starting to get the following errors in the log
04/13/2005 18:01:16 Starting FoxWeb
04/14/2005 10:40:05 Killed Channel 5: /intranet/positions_match.fwx
04/14/2005 10:40:07 Restarting Channel 5
14/04/2005 11:42:35 FoxWebCtrl Error: 9 (channel 1)
04/14/2005 11:42:41 Restarting Channel 1 /intranet/Registrations_ActivityHistory.fwx
04/14/2005 11:42:48 FoxWebCtrl Error: 9 (channel 1)
04/14/2005 11:42:50 Restarting Channel 1 /intranet/positions_details.fwx
14/04/2005 11:42:50 FoxWebCtrl Error: 9 (channel 2)
04/14/2005 11:42:52 Restarting Channel 2 /intranet/locum_find.fwx
14/04/2005 11:43:40 FoxWebCtrl Error: 9 (channel 3)
04/14/2005 11:43:42 Restarting Channel 3 /intranet/positions.fwx
14/04/2005 11:44:03 FoxWebCtrl Error: 9 (channel 4)
14/04/2005 11:44:05 FoxWebCtrl Error: 9 (channel 5)
04/14/2005 11:44:06 Restarting Channel 4 /intranet/alerts.fwx
04/14/2005 11:44:07 Restarting Channel 5 /intranet/Positions_Details.fwx
14/04/2005 11:45:27 FoxWebCtrl Error: 9 (channel 6)
04/14/2005 11:45:29 Restarting Channel 6 /intranet/alerts.fwx
14/04/2005 11:45:30 FoxWebCtrl Error: 9 (channel 1)
14/04/2005 11:45:31 FoxWebCtrl Error: 9 (channel 2)
04/14/2005 11:45:32 Restarting Channel 1 /intranet/positions.fwx
04/14/2005 11:45:32 Restarting Channel 2 /intranet/Locum_fileview.fwx
14/04/2005 11:45:58 FoxWebCtrl Error: 9 (channel 3)
14/04/2005 11:45:58 FoxWebCtrl Error: 9 (channel 4)
04/14/2005 11:45:58 FoxWebCtrl Error: 9 (channel 5)
04/14/2005 11:46:00 Restarting Channel 3 /intranet/Positions_Details.fwx
04/14/2005 11:46:00 Restarting Channel 4 /intranet/alerts.fwx
04/14/2005 11:46:01 Restarting Channel 5
04/15/2005 09:36:05 Killed Channel 2: /intranet/registrations.fwx
04/15/2005 09:36:07 Restarting Channel 2
04/15/2005 10:52:46 Killed Channel 4: /intranet/positions_match.fwx
04/15/2005 10:52:57 Restarting Channel 4
04/15/2005 12:21:34 Killed Channel 6: /intranet/alerts.fwx
04/15/2005 12:21:35 Restarting Channel 6
04/19/2005 08:52:29 Killed Channel 3: /intranet/positions_match.fwx
04/19/2005 08:52:33 Killed Channel 1: /intranet/positions_match.fwx
04/19/2005 08:52:33 Restarting Channel 3
04/19/2005 08:52:39 Restarting Channel 1
Sent by FoxWeb Support on 04/13/2005 07:24:12 PM:
This is odd.  I really can't think of a reason why channel 3 would be any different than other channels with the exception of the port number (each channel uses a different TCP/IP port to communicate with other components).  It's possible that the port used by channel 3 is also used by another application on your server.  I think that possibility is unlikely because the channel starts fine when FoxWeb is restarted.  If the port was being used by another application, then the channel wouldn't start in the first place.
 
In case you want to try changing the port, you can do so by modifying the following registry entry:
 
\\hkey_local_machine\software\Aegis Group\FoxWeb\CurrentVersion\Channels\Port1
 
From what I remember, you only need to change Port1.  Other channels use sequentially higher ports.  For example, if Port1 is set to 15823, channel 2 will use port 15824, channel 3 will use 15825 and so forth.

FoxWeb Support Team
support@foxweb.com email

Sent by James Williams on 04/13/2005 06:40:44 AM:
Sorry also forgot to mention that out of the 6 channels, channel 3 is missing and has been missing for the last week (has not auto-restarted). It returns on a foxweb stop then start, but if we lose a channel it always seems to be channel 3. I have cheked the server and there are 5 vfp7.exe files running and 1 FWStart.exe, so why is channel 3 not restarting it does not appear to be locked.