Rafał, snapshotting these big amounts of data in the schedulers feels like a bad trade-off, especially since this is not a core feature of the system, but I guess I will just do some tests.
Storing the data in Cassandra with a hash as partition key to distribute load, and the timestamp and user as cluster key, and querying the database at intervals, looks like a promising alternative to me which I will also look into. Thanks for the discussion! - Arno Am 13.03.2017 um 21:01 schrieb Rafał Krzewski: > Arno, > > yes, you'd have to to send a message resetting the timer on each > interaction. I agree that it can become a problem. > You could split the state of the scheduler actor by creating a bunch of > them and using consistent hashing for assigning a subset of users > entities to each scheduler. Nevertheless the totality of the scheduler > actors' state will be full mapping userId -> timestamp, so I'm not sure > if that helps. > > cheers, > Rafał > > W dniu środa, 8 marca 2017 16:34:49 UTC+1 użytkownik Arno Haase napisał: > > Rafał, > > thank you for the fast reply! > > I had though about using a separate 'scheduler' actor but could not > quite get my head around it. I want user inactivity to trigger an > action > - wouldn't I have to send an an event to the scheduler actor whenever > any user interacted with the system to 'restart' that user's timeout? > And wouldn't the scheduler actor's state become prohibitively large, > containing a 'last active' timestamp for every user in the system? > > The core of the problem for me is that only a small fraction of user > interactions will be the 'last interaction before a timeout', but the > application has no way of knowing in advance which they are. > > Does that make sense? Any advice is much appreciated! > > - Arno > > > Am 08.03.2017 um 14:07 schrieb Rafał Krzewski: > > Hi Arno, > > > > I think you need a separate persistent actor that will keep track of > > long-term scheduled events. It will be active at all times and > keep an > > agenda of future notifications in it's persistent storage. It will > use > > ActorSystem Scheduler to wake itself up when it's time to send out > next > > (batch of) notification(s). A message sent to a shared User entity > will > > activate the target if necessary. > > I think it will be reasonable from resource management point of view, > > and also safe against system restarts. > > > > Cheers, > > Rafał > > > > W dniu środa, 8 marca 2017 06:35:11 UTC+1 użytkownik Arno Haase > napisał: > > > > I am working on a social media kind of system, and we have users > > represented as sharded persistent entities. Now we want to > react to > > users' inactivity, e.g. sending out 'come back' emails to > users who > > were > > inactive for a week. > > > > Any suggestions for how to implement that? Scheduling (and mostly > > cancelling) messages in every user's actor seems both wasteful > and > > unreliable, at least if we remove long unused entities from > memory. > > > > All ideas are welcome! > > > > - Arno > > > > -- > >>>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>>> Check the FAQ: > > http://doc.akka.io/docs/akka/current/additional/faq.html > <http://doc.akka.io/docs/akka/current/additional/faq.html> > >>>>>>>>>>> Search the archives: > https://groups.google.com/group/akka-user > <https://groups.google.com/group/akka-user> > > --- > > You received this message because you are subscribed to the Google > > Groups "Akka User List" group. > > To unsubscribe from this group and stop receiving emails from it, > send > > an email to akka-user+...@googlegroups.com <javascript:> > > <mailto:akka-user+...@googlegroups.com <javascript:>>. > > To post to this group, send email to akka...@googlegroups.com > <javascript:> > > <mailto:akka...@googlegroups.com <javascript:>>. > > Visit this group at https://groups.google.com/group/akka-user > <https://groups.google.com/group/akka-user>. > > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > -- >>>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>>> Check the FAQ: > http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google > Groups "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to akka-user+unsubscr...@googlegroups.com > <mailto:akka-user+unsubscr...@googlegroups.com>. > To post to this group, send email to akka-user@googlegroups.com > <mailto:akka-user@googlegroups.com>. > Visit this group at https://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
