Our php programmer found the reason for intermittent page failures was
because a script call never returned. The pages do lots of other heavy
php/FM activity with no failure. This is the only script call, though
we'd like to use more. The script is used heavily internally and
doesn't get hung up. The first thing the script does is create its own
log entry with the parameter it was sent. Looks like the script is
starting and logging and has a proper parameter and it looks like it
completes it the job
Why don't you get the script to log it's completion too? That way you
can be sure it completes, or not.
What do you expect to be returned? The normal result is the found set.
If your script does not leave a found set, or exits with an error, you
will receive an error rather than a record set. It's a different type of
data bundle and has to be handled differently.
I'll add logging completion, but I can see it gets to the end of its work.
It isn't intended to have a return value. The script just does internal housekeeping. So the result php gets simply acknowledges the cmd to run the script was received and the script done. It should wait for it to be done so the web page doesn't try to do other stuff affecting data while this script runs. The thing it is periodically just gets no response and the page hangs waiting for that. I would just put that done to an internet communication failure but we don't have any of that problem with the many other calls we do.
Are there any errors showing in the server log?
In one system that I worked on we added an "error" table which stored
all the FM error codes, the FM explanation and our own customised
message. Whenever a script received an error that prevented it from
returning the expected result we used the error code to search the error
table and passed a message as parameter to the record. The web app then
received a positive result, with an error code, and a meaningful message
that pinpointed the code point that generated the error.
This isn't an answer to your question, but a suggestion.
If the script is not necessary to the running of the page then why don't you use AJAX to have it called in the background? The page performance should improve because I've found that calling a script via PHP is a heavy operation regardless of how simple it is (it has to create a virtual user on the server and perform the script which is much heavier than using the PHP API to directly manipulate data).
I don't know ajax but the php programmer probably does. Interesting to know about the load of calling a script. It seems so simple I assumed it would be easier on the system than calling for a sort or fetching data out of records.
This didn't seem to post so... I'll add more logging internally and try to get clues out of that, rather than more php code to try to sort it out.
Also more calls are failing and it's looking like internet communication errors.
It may be time outs, you may want to look at your settings to see if
extending the wait time will fix the problem.
Carl, just to be clear what you're saying, calling a script isn't a bigger burden on php, it's a bigger burden on the FM server because of making the virtual user?
Calling a script on FM Server is slower than doing something directly with PHP. E.g. using PHP to find a record, then set a value in that record is quicker than doing the equivalent by calling an FM Script on the server, that's because the server creates a virtual user to run the script, so the extra lag is caused by FM Server.