Can someone explain this one...

[danmcccomb]

I have a client that relies heavily on Filemaker for internal database needs. Some of those files also serve as the back end for web pages. FileMaker Unlimited 5.5 is installed on an iMac 350MHz with 512MB memory. The files are on a QuickSilver G4 with FileMaker Server 5. Both machines are in a server closet at their site with a T1 connection to the net. Both machines are running OS X 10.3 Panther.

There are 91 web files in the web folder on the Unlimited machine. Perhaps 10 to 20 of those are dormant, out of date, or otherwise not active. There are 94 files open on FileMaker Server. One file is the launch file for FileMaker Unlimited 5.5. It opens a set of 25 files by means of a default layout which has related fields from these 25 files. Additional files are opened as needed when called by script steps or calculations. Fully deployed (run down the files and open every window, so everything is open) there are 48 files open.

The fault we are concerned with is that periodically and irregularly, at least once a day, FileMaker Unlimited hangs up, displaying the spinning beach ball, and needs to be force quit and relaunched. At that time, the Activity Monitor on the web server machine shows the cpu fully occupied, with FileMaker using 66%-80% of the cpu (varies but basically using all the resources not used by other apps). Other applications and the OS are unimpaired. I have often started BBEdit, Activity Monitor, Console, Terminal, with no problem while FileMaker is hung up. FileMaker server is still OK, since other users in the office are not impaired by this fault.

I have run many tests, and have found nothing wrong with the databases. I don't mean to say I'm satisfied that any of these issues are eliminated as the source of the problem. I'm obviously overlooking something. In addition to the tests:

Discovered a very large resource file (1 record, 14Mb) which has a huge graphic in a container field on the layout it is set to open on. I rearranged it so the graphics were on a different layout. The hangups persisted over this last weekend.

I found a forum thread that seemed to be a similar problem which was solved by adjusting a parameter called vnodes. Dunno what that is but I followed a recipe for adjusting this parameter larger, It had no effect.

Any ideas, anyone?

[Vaughan]

Are you using IWP or CWP?

What version of Web Companin are you using? Check the FMI web site, updated to WC are often listed separately from FMP Updates.

[Martin Brändle]

We had that once, too. These crashes may come from ill-defined HTTP requests of internet worms and search engine spiders. I say may because one can often not track them in the access log, because the access log is only written back to the file system in bunches, and the incident may have happened before the next access log buffer is filled up and written.

Make sure that you have the newest Web Companion update.

Enable the firewall and just allow for ports 80 and 591. System Settings - Sharing - Firewall ... (and of course you should also enable those services that you need).

After application of these two measures, we never had a crash again!

Martin

[danmcccomb]

We're using CWP, and IWP is turned off.

Re: Upgrading to current version of Web Companion, looks like I neglected to upgrade the installation on the current machine. I did that this morning (FM 5.5v2, WebCompanion v4). Will let you know whether that does the trick.

[danmcccomb]

As I suspected, the upgrade wasn't the problem. I upgraded FileMaker and Web Companion this morning and it hung up at 1:30 pm according to the access log. I'll try the firewall fix next. Any other ideas, anyone?

[DykstrL]

We were having the same problem with FMU 6.0v3 and OS X on a 450mhz G4. We have never resolved the issue. Our solution was to go back to OS 9.2.2, since that worked flawlessly before we upgraded to OS X.

We have seen all sorts of possible reasons and possible solutions, but none worked for us. Our workaround was to reboot the FMU box 3 times a day, but that got to be a pain, so we went back to OS 9.