Hi, is the Akka scheduler the recommended way to schedule some activity for a player e.g. in a few hours, or does Metaplay build something on top which is preferred? The Akka stuff seems good to trigger things for the PlayerActor so I'd be happy to go with that but just wanted to verify. https://getakka.net/articles/actors/schedulers.html the examples on the bootcamp page include:

csharp
system
.Scheduler   .ScheduleTellRepeatedly(TimeSpan.FromMinutes(30), TimeSpan.FromMinutes(30),
    someActor, someMessage, ActorRefs.Nobody,
    cancellation); // add cancellation support

https://github.com/petabridge/akka-bootcamp/blob/master/src/Unit-2/lesson3/README.md

Timers would actually not work because they only run during the entities lifetime (maybe there's some way around that but that's how it works for us generally)

i want this to work when the player is offline we may want to send a notification when the periodic operation results in a state which exceeds a threshold, for example i made a DB scan job for this i run it every 5 minutes now and the timing for this is usually once per 1h .. so it does not need be accurate, something like +/-2 minutes is fine. but it's individual per player

Yeah, scan jobs that loop over all the players will get quite slow and/or resource-hungry when there's lots of players, so although it can work ok with a small player base, it may not be the ideal long term solution for this. If the operation has predictable timing (i.e. you can calculate when the player's next notification should happen), this could be a device-local notification instead. If it's not predictable, but rather need to try the operation and check the outcome to know if the notification needs to be sent, that might need some kind of custom server-side mechanism. Like an entity to which you could register these per-player scheduled operations and that entity would handle the timers and wake up the player entities at right times. That could possibly be made into a generic SDK feature but at the moment it does not exist. At big scale, the implementation would probably need some sharding to avoid dealing with huge player lists in a single entity. Or, your idea about the time-for-next-check DB field sounds like a viable approach as well. It could be a separate database table (separate from the main Players table) with an index with the time-to-check column, to ensure fast queries. Regardless of the actual mechanism, proactively doing server-side operations for all players can be troublesome as it can cause spikes if the operation happens at roughly the same time for all (or very many) players. If the operation is known to happen at different times for different players, and therefore spread out smoothly over time, it should be okay.

oh the dedicated entity for this would work very well i think! i have a few of them for other purposes and it's a very nice mechanism thanks! i'll copy-paste the info to an improvement-issue about this for later