I'm wondering the impact of long delays in scheduled events, on the order of perhaps one day; in the past I've implemented this as an event to hold an expected delay and compares against a start time stored as actor state. The downside of this is frequent tick events sent to check this duration(which may have some socket overhead even when sending to self()), which looking at LightArrayRevolverScheduler is pretty much what happens already with scheduleOnce(). My initial concern was that an underlying implementation of an ExecutorService would end up holding a thread open for a long time and exhausting the thread pool. Is there a similar risk with Akka's infrastructure of this happening, or is LARS only holding the event in TaskQueue and consuming a thread when the task actually runs?
-- >>>>>>>>>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
