5 Replies Latest reply on Jan 31, 2016 7:11 AM by Vincent_L

    Filmaker Server 14 is NOT a robust product

    Vincent_L

      Hi,

       

      I'm sorry but truth to be told filemaker server 14 is not robust.

      Here's what just happened to me (again)

       

      I changed 10 field declarations and TO in my main table, then I clicked ok to save the changes.

      Yes I was developing live (I know that's not recommended, but I'm a in house dev, I have no choice, and since Filemaker doesn't provide any real data separation model… Nad also, as the feature exists it should work)

      Of course many users were using the file. But also a scheduled server side script.

       

      I do this daily, but this time, maybe there were more changes, maybe the server side script came into play, but still after 10 minutes the changes weren't committed and people started to complain they couldn't do anything.

       

      But the fmserver process what only unit 0,1% and my fas client also. So of course if no-one is churning out CPU time, it could get long. I kept patient for 20 minutes and then decided to act. And now it's the par that show the non robustness of FMS

       

      I decided to disconnect the scheduled server side processing script : with the GUI : no reaction from the GUI, then in command line.

      I tried 10 times in command line. No go

       

      I then decided to disconnect all client one by one to just be able to keep my client (which does the schema mod), practically no reaction. But on insisting, some clients got disconnected after a long time. The webdamin GUI sin't refresh well, as client disconnect in command line stil appeared in GUI.

       

      The lack of proper web admin GUI synchronization is a well documented issue, that is stil not addressed by the way.

       

      So I kept trying disconnect for 30 minutes. 5 users including the server side script and my connection remained.

       

      Since nothing changed for minutes, and CPU on client and server still idling, I decided to kill the fmased process. I thought it would disconnect the  server side script client. Wrong : even thought fmased was killed, the server side script client was reported to be connected (with GUI and command line).

       

      Therefore I finally decided to disconnect my client. Which worked albeit very slowly.

      Then I decided to reboot everything, so with command line I first close all files, it worked. But even though all the file were closed according to command line, GUI was still showing the server side client connected and 10 files not closed.

       

      Also, only 2 files were reported closed by the server log

       

      I decided to stop the server, with GUI, the "power button" did grayed out, but then nothing happened, refreshing status page, server still on.

       

      I then used command line, the closing command never ended

       

      I finally rebooted the mac.

       

      - Why did my modification took so much time to apply, WITH NO CPU USAGE, nor on server or client.

      - Why scheduled server side script client disconnecting didn't work

      - Why client disconnecting took so much time WITH NO CPU USAGE

      - Why scheduled server side script client did not disconnect when I killed fmased

      - Why the webamin GUI is such out of sync

      - Why the log didn't reported all the file closing


      So those problems and questions highlight the lack of robustness. The server should be able to kill anyone immediately, and the GUI should be in sync.

       

      If schema modification can cause such problems if server side script is running on same table, then, the client should tell the dev "hey by the way a server side script is using your files, it will take ages to register your changes, do you want me to apply the mode once the server side script is done ?)

       

      Thanks for improving this

        • 1. Re: Filmaker Server 14 is NOT a robust product
          Fred(CH)

          I know that won't help but yes, it happened to me recently that my modifications in Database management weren't applied. I was blowed.

           

          I didn't noticed any other specific error.

           

          I knew it was not my mistake since i was able to play with the new fields in browse mode and haven't any other database opened.

           

          After closing and reopening the file, my changes were gone.

           

          It never happened with FMS 12 (my dev server never was in 13).

          • 2. Re: Filmaker Server 14 is NOT a robust product
            TSGal

            Vincent_L:

             

            Thank you for your post.

             

            I am unable to speculate why this non-responsiveness occurred.

             

            If you want, send in your log files for the time this non-responsiveness occurred so our Development and Testing can review the logs for clues.  I have sent you a private message with instructions where to send the log files.

             

            TSGal

            FileMaker, Inc.

            • 3. Re: Filmaker Server 14 is NOT a robust product
              TSGal

              Vincent_L:

               

              I received your log files.  Thank you.

               

              The files have been sent to Development and Testing for review.  When I receive any feedback, I will let you know.

               

              TSGal

              FileMaker, Inc.

              • 4. Re: Filmaker Server 14 is NOT a robust product
                TSGal

                Vincent_L:

                 

                Here are some answers to your questions from Testing:

                 

                > Why did my modification took so much time to apply, WITH NO CPU USAGE, nor on server or client?

                Proces samples are critical in this state to get an idea of what actions were being performed on the server.

                 

                > Why scheduled server side script client disconnecting didn't work?

                See similar question below.

                 

                > Why client disconnecting took so much time WITH NO CPU USAGE?

                Difficult to speculate without client stack traces.  The most common performance bottleneck is disk read/write and network.

                 

                > Why scheduled server side script client did not disconnect when I killed famed?

                The script session data is stored within the adminserver process.  Termination of the scripting process killed the script itself, but the notification wasn't sent to adminserver that the script ended.  You are left with a ghost session listed.

                 

                > Why the webadmin GUI is such out of sync?

                Unknown.  This appears to be a process communication issue.

                 

                > Why the log didn't reported all the file closing?

                The server likely had issues closing the files that was taking time.  Turning the machine off aborted the closing process.

                 

                TSGal

                FileMaker, Inc.

                • 5. Re: Filmaker Server 14 is NOT a robust product
                  Vincent_L

                  Hi TSGal, thanks a lot to support for those answers, much appreciated.

                  I'll try to sample the processes next time

                   

                  > Why client disconnecting took so much time WITH NO CPU USAGE?

                  Difficult to speculate without client stack traces.  The most common performance bottleneck is disk read/write and network.

                   

                  Well it's on SSD, there was no hi disk usage, I checked in activity monitor, nor I/o

                  Network was gigabit, no problem either

                   

                  > Why scheduled server side script client did not disconnect when I killed famed?

                  The script session data is stored within the adminserver process.  Termination of the scripting process killed the script itself, but the notification wasn't sent to adminserver that the script ended.  You are left with a ghost session listed.

                   

                  That's why I wrote "not robust". You can rely on a process to notify, you have to have a double checking mechanism. So of course you can have notification, but let's say that if during, let's say 5 minutes) you did not had any, then the awake process (in that case the admin) has to check the other process existences, and then act accordingly. You can't tolerate to have Ghosts / Zombies.

                  True I killed the process, but the process may crash itself also, you need to have a double check mechanism. Robustness is talking care of the unexpected.

                   

                  > Why the webadmin GUI is such out of sync?

                  Unknown.  This appears to be a process communication issue.

                   

                  The web admin is very often out of sync, of course that's a process communication issue, that's why it needs double checking.

                  The web admin is a critical tool, it must be up to date  no matter what because :

                  - we could take bad decisions harming the files

                  - if the web admin thinks that a server side script is running, while it does not, this will prevent subsequent exception of that server side script. I've a warehouse stock import process that runs every 20 minutes, if it's stuck because admin got the wrong feeling it's still churning out, the script won't launch 20 minutes laters : consequence after few hours my stock is wrong !

                   

                  > Why the log didn't reported all the file closing?

                  The server likely had issues closing the files that was taking time.  Turning the machine off aborted the closing process.

                   

                  Well, command line admin reported some file were closed, but the log didn't

                   

                  Webadmin is notoriously out of sync, that needs fixing. Sometime even GUI and command line admin display different indo.

                   

                  So to me it appears that there's the server processes, then the command line admin, then the web admin GUI, which both admin able to be out out sync, at their own pace, to the server processes. That needs to change