I think you need to give more information at least:
- FileMaker Server Advanced, version
- Operating System (Win Mac) and version.
- Hardware, memory etc.
- Will the WPE fail at specific tasks or just when more users are connected (how many users etc)
- Can you reproduce the situation causing the failure?
- How often does it fail?
- Any observations on when it fails?
Please measure the performance/proessor load on the computer running WPE (In a one machine deployment this is the FileMaker Server).
- On Windows Right Click on the bar at the buttom. On Mac Go to /Applications/Utilities and use Activity Monitor.
- Now open the solution with relevant browser(s) from other computers and use it via IWP. Go through the solution and use it as a real user would.
- Follow the load on the FileMaker Server (and if it is a two/three machine deployment on the WPE machine).
Tell us about your observations. How is the processor load, when is WPE crashing?
Numbers of users and hits too... If you haven't allowed enough sessions for IWP or enough cache, this can happen.
I have Filemaker Server 11 Advanced on a MacPro and the cache size is 800 mg (max) and I allow 100 active sessions. But it's when three people at the same time use a specific script, the webengine stops. Here's what the log says "wpc1 Error: 400"
I will try to go in and change the script. No problem if one person is doing it but if 3 or 4 people do it at the same time. It crashes the web engine. I looked up the error but don't understand what is happening when I do that. Thanks for your help. Any other suggestions. This is a 1 machine installation.
Here's another error it says ajp_service::jk_ajp_common.c(1953): (wpc1) Connecting to tomcat failed. Tomcat is probably not started or is listening on the wrong port.
And this is running on a single install Filemaker Server 11 advanced And we only have trouble with instant web publishing. It's running on a Mac Pro.
Jim, I saw something similar on a previous build of FMS Advanced, also on a Mac, and had the toughest time looking for the culprit. For our IWP stoppages, it had little (or nothing) to do with the number of simultaneous users, but we boiled it down to the script and/or layout.
Please check to see that you have the latest FMS 11 Advanced installed since there was a fix some time ago that resolved my issue. I never did find out the original problem.
Here's to hoping you are not using the latest version. I believe 11.0v3 solved the problem.
No doubt that you have already found and isolated the problem.
Try copying the scritpt for demo/test purposes. Divide it into sub scripts and then tryk activating it via IWP while holding an eye on the Activity Monitor on your Mac Pro.
What is happening now: Is it causing the processor burden to increase?
If so: Start analysing and changing until the problem is solved.
Question: Do you have a demanding subsummaries on the layouts shown, do you have complicated calculated fields based on deep relationships on the layouts shown, do you have portals with sorting/complicated calculations etc. etc.?
And a question: I suppose that you are using specific layouts for IWP, specific scripts for IWP and maybe also another specific interface file - thereby making sure that you are isolating the IWP functionality and are "scripting" and "layouting" specificly for IWP?
It's a pretty simple table going to a list of scores. There are 18000 records in the scores.. The layout that I go to has 7 or so portals.
But here's the list of fields.
Here's the relationships:
But the errors in the tomcat connection. Is that possible? Could it be that I have a bad copy of the server 11? I have tried it with another deployment of Filemaker Server 11 Advanced and it does the same thing on that machine.
Here's the other deal. The script is really small but it's always when that script runs that the webengine crashes. Here are the script steps.
This works fine while using Filemaker Pro. It's only when accessed using IWP that it blows up.
Thanks for your help. If it would help to see the application, I'd be glad to share it with you.
Maybe try splitting the 7 portals into separate layouts, at least for testing. I had several portals (four?) on a layout that caused an IWP problem a year or so ago.
Several users who solved their problems claimed it had something to do with alignment of fields within the portal. Not sure if there was any real portal-IWP issue there, but most people admitted they had more than one portal on the offending layout so it seems possible.
Scott is right, but before doing this please do the testing with measuring of processor load that I wrote about. Then afterwards you can retest with each part and isolate the problem and solve it.
When you know what the problem is we/I will be able to advise you on how to optimize.
Thank you. I'll try to separate those into several layouts. It's worth a shot. Thanks.
I measured the processor last night. There was hardly a hiccup. Everything was fine. I tried it with iwp and fmpro. I filtered the processes with fm and web. Is that enough?
It is a back-to-basics troublshooting thing... isolate the bit that doesn't work by eliminating those bits that do... and of course you can always put them back together again when fixed.
That said, I have layouts with lots of portals (10 in one case) that work fine in IWP... I imagine it is something amiss like a field from an unrelated table or a script step that is not IWP compatible or something that will turn out to be really obvious once you've found it... ;-)
It sounds like the problems may be related to this: http://forums.filemaker.com/posts/ff1280e6d0
The thread is pretty long so you may want to read the first post and then scroll down towards the bottom, toward where the answers have been figured out.
In my case I found there were problems using self joining portals and opening new windows... Since then I have tried to make IWP solutions work using only one window, except where absolutely necesarry. I believe FileMaker Support helped establish that the problem was directly related to a record being modified by two (virtual) windows at the same time - so I have go into the habit of making sure I use the Commit Records script step in every script that opens a new window.
Hope this helps.
Just saw James' post above, and I had used the same link to resolve my IWP portal issue. Portals that reference a table more than one hop away seemd to be problematic, as well as some self-referenced portals.
I could not get IWP to crash, no matter how many users were active, after I resolved the issue. I could, however, get it to crash with only a few users accessing a layout with multiple portals. No high processor usage in any case for me.
Also, as James mentions, remove any Window commands within your script(s).
Did you confirm that you have the latest FMS version running?