My use case is: My back-end database updates about once a minute (but at unpredictable times). I would like clients to react to this change within about 1 second. Processing and sending this data to clients (sending about 250k data points) was taking a bit longer than a second.
I’d love to get rid of the callback, but as far as I can tell the client must poll for changes - there is no way for the server to initiate data exchange with all clients.
You are right about the red flags, and the work around is very easy: make sure the callbacks finish fast enough - or slow the client polling down slightly. The documentation has plenty of ideas about how to do that - in my case raising
PreventUpdate when the data hasn’t changed is more than enough to make my app work (I discovered this feature as part of debugging my problems!) - so on average callbacks finish in milliseconds and once a minute a callback takes slightly longer. I could also down-sample the data, or poll every two seconds, or perhaps cache the callback result (assuming its not the sending of the data that is the problem).
So my question is more academic than practical (and more of a suggestion or feature request rather than needing any immediate help!). First, can we detect re-entrancy in callbacks (perhaps so we can log a warning that our app has become too slow)? The answer is yes, but I can’t figure out a simple solution. Second, if we have re-entrancy, is there a quick solution such as aborting all later calls until the first call finishes? I can’t find a solution to this - my example above comes close but the client doesn’t update.
I think it would be a useful recipe (or feature, if it needs work to support it). In my experience re-entrancy is at best unexpected, and at worst a bug, so giving the user a few tools to detect and prevent might save some grief.