Hi Sandy, sorry this fell through the cracks, but better late than never!
12 jul 2014 kl. 01:26 skrev Sandy Wiseman <[email protected]>: > Hi, > I've read the Akka docs, played around with spray, read a billion blogs, read > a couple books but all the examples have very simple actor networks. I'm > wondering what the recommended practices is for a few scenarios (I'd prefer > not to use Spring, but some these feel DI-ish). Not wanting to use Spring should not be an issue, let’s see what we can come up with. > > ---- > > Spray actor-per-request (it's not important that it's spray) > > A unit of work arrives in one actor and you want to create an actor to do the > actual work while the first actor waits for more work to arrive. The worker's > identity is not important and it only lives until the work is done. > > Do people just build the actor directly? Seems bad because you can't test the > actor gathering the work and the worker separately. Passing a worker factory > function when the gatherer actor is created? Seems like it gets unwieldy when > there are several services, repositories and the like around. Providing a > worker factory stackable traits? I’d go with a factory trait myself, although passing in Props works just as well. It depends a bit on how many different kinds of worker actors are needed within that particular Spray router. > > ---- > > Application with several services and repositories > > A dozen or so different components, each of which is an actor. Should each > component get created when the app is initializing, each component getting > its dependencies passed in via the constructor? or via an Initialize message? > Or should the stackable traits or cake pattern be used? (Most of our team's > experience is with Java so simpler and explicit is best). > > What about a component registry or "context" object either passed explicitly > to each component or globally accessible? > > Or give the actor components names and have components select their > dependencies by name at creation or initialization time? There will probably be a mix of these approaches needed: within a top-down hierarchy (which is mostly within one node, or it might include remote-deployed subtrees) you can usually pass dependencies as ActorRefs down during creation. Cyclic dependencies between siblings must be broken up by using initialization messages, but otherwise constructor arguments work well if the ActorRefs live higher up in the tree; otherwise it might be wise to foresee a later lookup in case the dependent component survives a failure of its dependency (e.g. using ActorPath and resolving via ActorSelection, or by passing an ActorRef to a coordinator actor really high up in the hierarchy who can then be asked). Starting off the communication between remote systems requires initial use of ActorPaths and ActorSelection, that is what these facilities are good for. The paths should be taken or derived from configuration, which is not only nice for the OPS team but also allows rewiring during tests. > > ---- > > Tens of thousands of actors holding state > > Think of a chat app where each conversation which lasts for an hour or two is > modeled with an actor. > > Is it reasonable to name each state-holding actor after it's conversation id? > The web-service would then pull the id out of the URL and use it actor > selection to find the state-holding actor. Or is it better to have another > registry actor that manages the mapping from conversation id to actor ref? > Does the answer change if we do clustering and some of the state-holding > actors are on remote machines? You might want to look at the ClusterSharding pattern in akka-contrib. > > And same questions about initializing the actor who creates the state-holding > actors which themselves might be created on the fly: http handler actor needs > to create a per-request actor which in turn needs to create the state-holding > actor. Its easy enough do this by writing little factory functions that > include nested factory functions that can passed down as actor constructor or > initialize arguments, is this common practice or is there better way? When using sharding you just need a reference to the ShardRegion actor and everything else is done behind the scenes by that one. In order to test things without setting up a cluster and sharding it would make most sense to pass the ActorRef of the ShardRegion into the http handler so that you can rewire as appropriate. > > ---- > > And a couple of closing questions: > > Do routers help any of this? No, not in general. Routers are very specifically intended for a class of scalability concerns. > > Are there libraries or components somewhere that abstract common actor > orchestration patterns? Most of these patterns are so extremely small that providing scaffolding would already be too heavy. With Actors it is just message passing, so the magic happens in how you design the messaging pathways through your application. > > And of course if I failed to find something out there or am missing the point > somehow, please send links. Sorry, no links today (since I don’t look these things up)—and the Reactive Design Patterns book is not yet complete enough to contain these. Regards, Roland > > Thanks! > Sandy > > > > > > > -- > >>>>>>>>>> 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. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- >>>>>>>>>> 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.
