7 Replies Latest reply on Apr 19, 2012 5:52 AM by PointInSpace

    FMSA12 & PHP - at wits end


      Hi all

      I have put myself between a rock & a hard place by going live at my workplace with 12 after extensive testing , then finding out that once over 20 clients have connected to the database, the web publishing starts to choke : Let me explain..



      I have been running FMSA11 since it was released on a decent dual quadcore windows box , running server 2008 (32bit) and web publishing has been fine. The site assistant was just the thing we needed to get jobs done quickly (I'm missing the PHPSA already...) and it just 'worked'.


      I then received the pre-release 12 server advanced from FMI , and running 2 clients & one iPad simultaneously (the pre-releases limit) , everything ran fine there too. This why I decided to install retail & go live with 12.


      Since going live with 12 , FMP clients run really well (tiny bit slower but we can live with that) , but some strange things happen once 20 or so clients & 5 or 6 PHP clients connect to the databases. The clients seem to stick around for around 10 minutes (even with the FM Server sample PHP technology test) after the request. Hitting refresh on the browser brings the results up immediately and without creating another FMPHP client session , it seems to use the original one. This client will stick around for 10 minutes , then disappear. This is very different behaviour to FMSA11 where you were lucky to see a php client in the list unless it ran a complex search , and even then it would disappear after 2 seconds.


      Once there are about 4 or 5 of these 'semi-ghosts' in the admin console , the PHP engine starts to throw error 500 & 802 errors to the clients and the logs in the FMS Console, to all web published databases.10 minutes later , they are all working again. Killing the ghost clients does not fix the problem (though it does really kill thenm unlike FMSA11). I did a bit of research and found that copying the FileMaker folder and Filemaker.php from the new api into the root of the website seemed to help with many problem web pages that were originally created with the site assistant. However the persistent clients are still happening. So through desperation , I created a VM running on a Citrix Xen server , gave it 8GB , 4 processors , fresh install of MS Server 2008R2 64 bit , and then FMS12A , and it's doing it too!!!


      I can't make it any more 'clean' than that , so does anyone else have the problems of the 'semi-ghost clients' and the web server randomly not processing WPE requests ?

      I have checked the logs for PHP , IIS & Filemaker , and the only reference is the Filemaker log showing an '802' error (file not found).




      Thanks in advance...

        • 1. Re: FMSA12 & PHP - at wits end

          I have a feeling we've been seeing a bit of this here with our server

          monitoring routines.


          I'm going to try escalating this with FileMaker.  I would highly

          recommend you call them and open a support case.  Please let me know

          directly if you do and the case number so I can add to my report as well.




               - John

          • 2. Re: FMSA12 & PHP - at wits end

            P.S.  Do you find that the 'fmsadmin restart wpe' command-line command

            doesn't fix things?  That's the behavior we've seen - only waiting for

            10-20 minutes clears it up.


                 - John

            • 3. Re: FMSA12 & PHP - at wits end

              Trying to shut down the WPE  with either the console or the command prompt does not fix the problem, but instead it crashes the WPE and a server restart is the only way to revive everything.

              • 4. Re: FMSA12 & PHP - at wits end

                I've also noticed the issue of PHP clients appearing in the Admin Console with FMSA v12, where in previous versions you were luckly to ever see them listed as you mentioned. I noticed that they remained in the list even after I had quit Safari on the machine I was accessing the PHP web site on so there was definitely no ongoing activity. Haven't had a chance to investigate further but definitely different behaviour to previous versions.




                FileMaker 8/9/10/11 Certified Developer


                - - - - - - - - - - - - - - - - -

                Phone: +61 2 9484 6565

                Mobile: +61 418 468 103

                Email: andrew@databuzz.com.au


                • 5. Re: FMSA12 & PHP - at wits end

                  Hi John,I spoke to FileMaker Australia today, and 3 hours after I had sent the server logs & config dumps to them, I received a call from them telling me they had escalated the issue to FileMaker u.s.

                  He did tell me that they had not heard of this problem before and sounded surprised when I told him there were others with similar symptoms. I don't know if it's related but our FileMaker server is a busy little beast, hosting 50db's with up to 60 concurrent users, all the while importing SQL tables with hundreds of thousands records several times a day. These problems seem to happen when it's the busiest.

                  Today I have simplified some of the heavy lifting databases by importing only the summaries from the SQL databases, reducing import times from around 40 minutes to 3 seconds. I'll see if the Php clients cause a server crack-up tomorrow, as the load should be significantly reduced.


                  One thing that is frustrating for me also is one of the solutions that we use internally is about 4 weeks away from being sold commercially (over 100 seats have already placed orders from all over Australia) and now I'm thinking twice about putting it out there. I hope someone can give some answers to this mystery ASAP cause for me it's more than just an inconvenience, it's my job.

                  • 6. Re: FMSA12 & PHP - at wits end

                    Another interesting thing Andrew is if you open another page on the same browser to the same server, the admin console does not 'add' another client to the list, nor does it update the 'connect time' field. It almost as if it just 'hangs around' just in case the client wants to query again, then after 5 minutes, it gets bored and just disappears.


                    How bizarre.