user10625

ESS over WAN causing FMS "broadcasting" weirdness

Discussion created by user10625 on Nov 15, 2017
Latest reply on Nov 21, 2017 by user10625

Product and version (e.g. FileMaker Pro 14.0.3) ---   FMP 15.0.4 clients, with Server 14.0.2

OS  ---  Server: Windows Server 2008 R2,  Clients: mostly Windows 7,  a couple of Macs.  (issue observed in both).

 

We have a Filemaker database with a bunch of tables that are shadowed/replicated in MySQL, via ESS.   The MySQL is on an AWS server in the cloud, so it's a WAN connection.

 

In the Relations Graph, we have Cascade Deletes hooked up between the FMP tables, and the MySQL tables.  So if an FMP record is deleted, it should be deleted in MySQL.

 

Sometimes our internet goes out, or the AWS gets extra busy or such, and then . . .when FMP goes to delete a record with a cascade, the user gets "hung" and has to force quit.   That is all well and good---- but then what happens is,  the user's thread "hangs" on the server even after they forced quit.  You can see it in Client Stats as a {352384756}  kind of thing, but yesterday I saw also in the  Activity / Users tab,  users logged in who had already forced quit, rebooted their machines, etc.   Also we saw an instance where a user was locking a record (got the standard message about "so and so is locking this record"), even though they were not logged in or had forced quit long ago.  Also saw a whole bunch of issues where various users didn't see up-to-date data in the system, for example,  there were records I knew existed but I had to log in again and then they appeared . . but then records created after that did not appear.  Etc.   In other words, Filemaker's whole "broadcasting" system went bonkers.  And this included users who had nothing to do with the actual cascade deletes---it seemed to effect everyone in randomly varying ways.

 

Backups seemed to work,  and I believe data was being written properly (at least I haven't heard anything to the contrary yet today), and once I restarted the server, everything was back to normal ***.

 

I guess the workaround is to avoid those cascade deletes, avoid deletions except by designated scripts. 

 

It does make sense that the user would hang, but it would be nice if they could simply force quit, and then FMS doesn't start going nuts. 

Outcomes