On Mon, Mar 24, 2014 at 8:46 PM, Justin du coeur <[email protected]> wrote:
> This has been stewing for a few hours, so I'm going to follow up: > > On Mon, Mar 24, 2014 at 12:27 PM, Patrik Nordwall < > [email protected]> wrote: >> >> I think opposite. It is easier to let each Aggregate decide, e.g. by >>>> using ReceiveTimeout. >>>> >>> > Slightly different question: are there other reasons to favor putting the > timeout in the Aggregate / child? I'm by no means sure of myself here, and > I'm genuinely interested in your viewpoint (since you have a lot more > practical experience with this than I), but here's my reasoning. > > I see two obvious reasons to put the timeout in the child: > > 1) It makes the code a little simpler, as you mention. > 2) It makes a certain amount of intuitive sense that the timeout for > Actor Foo should adhere to Foo itself. > Yes, then different Foos can have different timeouts, by deciding themselves. Might even depend on the data, e.g. WIP Customer stays in memory longer. The Passivate message in cluster sharding can be sent from anywhere to passivate a specific child. It can be sent from the outside, or from the manager itself, or from the child. The process to passivate is the same in all cases. /Patrik > > I'm not finding either of those arguments all that persuasive, though. I > don't much care about the code complexity -- I'm designing a library here, > so any complexity is buried. More importantly, I'm not sure I think it's > the right separation of concerns. > > The thing is, at the semantic level the timeout barely even exists: the > child Actor doesn't really care about the fact that it has a timeout. It's > really an implementation detail to address the more interesting issue, > which is memory pressure. And I think of memory pressure more in terms of > the *collection* of Actors, than any individual Actor. Architecturally, I > want to be able to say, "I am allocating 40% of main memory to this body of > Actors" in my configuration; the timeouts are one way of keeping that under > control. > > And the thing is, while timeouts per se conceptually adhere to the child, > most of the other techniques I can think of to deal with this don't. > Indeed, as I think about how I might make this more sophisticated, I find > myself wanting the Manager / parent to have more control. A simple (and > fairly long) timeout is great and appropriate so long as the system is > lightly loaded, but once we start seeing any memory pressure, I might want > to ratchet those timeouts down, or even move to a different algorithm (eg, > an LRU queue that shoots older children in the head more aggressively to > make room for newer ones, or which begins to pro-actively move children to > other nodes). All of the really serious approaches I can think of require > a more holistic view of the situation than can easily be handled in the > child. > > I may well be over-thinking this: truth is, most of the advanced > situations I am thinking of will probably want to be handled through the > Cluster Sharding system anyway, at least in the long run. But that's > roughly why I had been assuming that this logic would be living in the > Manager. Indeed, I had *started*, months ago, by assuming that the Manager > would have an LRU built into it -- the timeout idea came later... > > -- > >>>>>>>>>> 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 http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw -- >>>>>>>>>> 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
