Hi Alexandru, 10 mar 2014 kl. 23:01 skrev Alexandru Nedelcu <[email protected]>:
> On Mon, Mar 10, 2014 at 9:11 AM, Roland Kuhn <[email protected]> wrote: > BTW: almost all Future combinators are not concurrent (as in > nondeterministic), Futures are therefore very useful for modeling parallelism > without the concurrency pain. I invite you to scrutinize the > scala.concurrent.Future API for non-determinism and then see for yourself how > that is reflected in the types. > > Stating the obvious for Dr. Roland Kuhn :-), but in my opinion the difference > between a Future[T] and an ActorRef is that actors are too low-level and > general, whereas Future[T] is very specialized - the Future combinators > simply assume that Future is a container for a Try[T] result that will be > available either now or in the future, the actual moment being of no > consequence for the combinators that simply guide you through the happy path. An actor is simply an exchangeable behavior which reacts to incoming messages at its own pace. Actors and Futures are equally low-level and general; they also happen to model very different things :-) > The problem with Future[T] is that it can't be applied for example on > problems where streams and/or bi-directional communications are involved. An > ActorRef can provide an awesome implementation for Future[T] instances. > However, between an ActorRef and a Future[T], there is a need for > abstractions in-between. Futures very cleanly model local dataflow. Actors very cleanly model distribution and concurrency. My guess is that if you try to create an abstraction in-between then it will have the disadvantages of both and the advantages of neither. > I know there are already patterns and best practices for designing stuff with > actors, but whenever I work with actors, somehow I always end up with fragile > and tightly-coupled designs, precisely because I had to deal with low-level > stuff. E.g. actor A sends a message to actor B, but actor B could crash, so > now you're thinking of using an external queue Nope, A simply needs to resend. If that is inappropriate then that means that A does not really care about B’s response either. > that persists messages for actor B's return. But once that external queue is > operational, now you're thinking of redundancy for actor B, so you actually > want actors B1 and B2, but because you designed actor B as statefull, now > you're thinking in terms of primary / backup nodes Nope, this is the old traditional thinking: you will need to split up your state in order to distribute it over multiple actors; this is called sharding. Then you make every shard persistent and you’re good to go. > and maybe you want those messages to not be pulled out of that queue unless > they were processed in a reasonable amount of time by the primary actor, or > otherwise have a backup that takes over that responsibility. Or maybe you > have stateless B actors, so round-robin dispatching is not a problem, yet the > message processing itself is long and could crash, so maybe you want to try > again later with another actor in case it didn't finish in a reasonable > amount of time. Again: if there is an actor that is interested in things getting processed, then that actor will have to be the one which resends the job until it gets a confirmation. It’s like in real life: if your boss wants you to do something, he or she will bug you. If they don’t bug you, it can’t be important. > Then you realize that actor A should maybe send the same or different > messages to different actors, but then you realize that this is actually > tight coupling Nope, you send ActorRefs around to introduce actors to each other; very loose coupling. > and you actually want a channel on which actors could subscribe for the > messages they are interested in. Or maybe you want your cluster to scale > depending on the load, so you want to create actors dynamically depending on > runtime stats, yet this is a far cry from bringing up HTTP servers > dynamically in an AWS ELB environment, because it's more generic and those > docs give me the creeps. I can’t answer those creeps, but spinning up new cluster nodes on AWS or GCE to participate in a cluster—with automatic actor deployment—is probably even simpler than doing the same with fat HTTP servers (not sure what you were referring to here, so correct me if I’m wrong). > Somewhere in that process, my head explodes, especially given that I haven't > solved the first problem I always have, which is good future-proof design, > because actors don't guide your implementation at all and many times it's > totally non-obvious of what to do. The actor model is a completely generic model of computation, just like lambda calculus or the Turing machine. Therefore it is not surprising that the model itself does not guide you on its own. When in doubt, anthropomorphize (as I did above). > > Kudos on debating the deprecation of "sender". That's a step in making that > interface more solid. I also await eagerly on your Reactive Streams - I do > feel the need for an Rx streams implementation that also does back-pressure. Yes, fully agreed :-) Regards, Roland > > -- > Alexandru Nedelcu > www.bionicspirit.com > > PGP Public Key: > https://bionicspirit.com/key.aexpk > > -- > >>>>>>>>>> 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.
