Hot answers tagged

56

I'll talk about Akka/Scala, because I'm not familiar with Gpars nor with Akka/Java. In Scala 2.10, which includes the relevant part of Akka in the standard distribution, a Future is essentially a read-only reference to a yet-to-be-computed value. A Promise is a pretty much the same except that you can write to it as well. In other words, you can read from ...


42

Although the Actor Model is older than Erlang, the designers of Erlang only learned about the Actor Model after having designed Erlang, so some differences are to be expected. They followed parallel paths of evolution, though: the Actor Model was created by Carl Hewitt based on the message passing semantics of Smalltalk. Alan Kay, in turn had based the ...


24

This is a question I am interested in and I have been doing some research on. For other viewpoints, see this blog post by Noel Walsh or this question on Stack Overflow. I have some opinions I would like to offer: I think Akka, because it works with messages, encourages a "push mindset". Often, for concurrency, I would argue this is not what you want. Pull ...


22

It's worth considering what the actor model is used for: the actor model is a concurrency model that avoids concurrent access to mutable state using asynchronous communications mechanisms to provide concurrency. This is valuable because using shared state from multiple threads gets really hard, especially when there are relationships among different ...


22

I am not familiar with the Flow API. The term “lifting” comes from category theory. In programming languages such as Haskell or Scala, a lift function takes a function A => B, and somehow performs magic so that the lifted function F[A] => F[B] can be applied to a functor or monad F[A]. A concrete example using Scala's Seq container: Assume we have a ...


20

According to wikipedia, they are the same concept: In computer science, future, promise, and delay refer to constructs used for synchronizing in some concurrent programming languages. They describe an object that acts as a proxy for a result that is initially unknown, usually because the computation of its value is yet incomplete. Some libraries may ...


16

Actor Model The actor model is computer science strategy for building applications that handle lots of concurrent computation and stateful processing. It's not the only strategy but it's a very well tested, simple, and reliable approach that moves computation into actors, which communicate through messages that they process one-at-a-time and in order. Akka ...


13

Your intuition is correct, IMHO. Using actors everywhere is like having the proverbial hammer and seeing only nails. The Erlang best practice is to use processes/actors for all activities that happen concurrently. That is, just like in real life. Sometimes it is difficult to find the right granularity, but most of the times you just know by looking at the ...


11

They don't mean reactive as in functional reactive programming, they mean reactive as in the reactive manifesto, which is a more generic term for a movement to build software that is event-driven, scalable, and resilient. It's a relative recent movement and the term hasn't really caught on.


9

I'm going to write about the Actor Model in general (not just Akka) in comparison with other concurrency models such as the classical lock-based concurrency and the neat transactional memory. Advantages Easier concept to understand and use Lock based concurrency is difficult; in particular is very difficult to get it right because there are many concepts ...


7

One of the advantages of message-processing models like actors and agents is that the traditional concurrency problems (primarily synchronization of shared state) are no longer a problem. The actor can keep private state and update it freely without locks. The actor framework ensures that only one message is processed at a time. With serialized processing, ...


7

I'll add a bit here because I have been working with a plethora of Futures in Java as of late but have a background in Scala/Akka development as well. This answer will mostly duplicate what has been said but will point out the plethora of implementations in popular use today on the JVM. First, original poster mentions using get and blocking - please never ...


6

The term to lift can of course have different meanings depending on the context. In generic programming it describes the process of abstracting to the next higher level. For example, you could have two pieces of code, one type with int, and the other with float. Lifting this code would mean something like templating the method with a generic type T that ...


6

I think, your question is not specific to Akka.NET exclusively. So I'll answer it being Akka/Scala developer. 0 Not everything is an actor. Functions are still functions with all that functional composition and purity. Actor model becomes very useful when you extend beyond CRUD in the land of Domain-Driven-Design and Hexagonal Architecture. I can't tell ...


5

You state correctly that transactions and locking are needed to deal with shared mutable state. And also that in an actor system, there is no shared mutable state. So it seems you've already answered your question yourself. I see that it can be necessary for some actor to lock one or more other actor(s) to send them several updates such that no other ...


4

These sorts of concepts are usually easiest to understand with a concrete example. Consider the following excerpt from this Flow API example: Flow(text.split("\\s").toVector). // transform map(line => line.toUpperCase). // print to console (can also use ``foreach(println)``) foreach(transformedLine => println(transformedLine))....


3

You say to consider Slick as an example. Slick will use JDBC, and thus will use blocking I/O, i.e. the thread will not be available to do other work while it waits for the response from the database. You don't want to use your default Akka dispatcher for that. You could define a separate execution context for your database operations and use that. I think ...


3

Since the Akka docs state that Actors should not block (on IO, sockets, ...) unless it's is really unavoidable, it sounds like there might be little value in having actors wrap transactional services, of which I'm assuming the majority will be backed by transactional databases. There might be other reasons to using Actors of course (the remoting, durable ...


2

Fault tolerance is one of the key concepts of Akka and "let it crash" is one of their mottos. Akka's mechanism for handling failures is called supervision, and it's right there on akka.io/#supervision: Actors form a tree with actors being parents to the actors they've created. As a parent, the actor is responsible for handling its children’s failures (so-...


2

Actor model doesn't magically solve all the troubles. It just makes such an abstraction of concurrent programming that helps reasoning about solutions. There are two major aspects of Actor Model, which make it very useful in my practice. First of all, when IT solves a business problem, what it does is effectively translates business processes and rules to ...


2

I would suggest you to create something like EmployeesManager. As a Manager this one class particularly does not have a state but will be used to manage other actors that can have state. This will receive all messages. Once Manager receives command that a particular Employee be marked as present , it will get actor referece by providing the ID, similar to a ...


2

The reasons why you would use Akka.NET are listed right on the front page of their website. You would use it when you need simple concurrency & distributed computation, using high-level abstractions like Actors and Finite State Machines rather than threads and coroutines. Some other characteristics of Akka: High Performance: 50 million msg/sec on a ...


2

If child actors are short-lived workers, while supervisor is some static service - better put all messages it accepts in the supervisor's companion object along with the props factory. All clients will see it as the supervisor's protocol. Workers being hidden behind their supervisor. But if you have a set of messages that pass between your actors across ...


2

I think you may want to read about Passivation. An entity actor is loaded (recovered) when you send a message to it, and can passivate itself when it receives timeout. Using passivation, you can avoid having all users loaded in memory.


2

You want to look at Akka Cluster Sharding. This complements Akka Persistence to distribute the instances that are currently kept in memory in the cluster and manage their lifecycle. Also keep in mind that Akka is - by design - a rather low-level toolkit. For an easier getting started experience with event sourcing and cqrs based on Akka, you might want to ...


2

The most straight forward approach is probably to distinguish verified emails from unverified emails within your model, and have a single actor responsible for verifying a given email address. (The simple versions are that you have one actor responsible for verifying all email addresses, or one actor responsible for verifying each email address.) That ...


2

“State” in this context always implies mutability. Thus, “immutable state” isn't state, it's just immutable data. There is no general problem with sharing immutable data structures between actors. If the data is not changed, there's no useful difference between a shared copy and two separate copies of the data. However, there might be concerns from a ...


1

On https://gitter.im/akka/dev, Konrad Malawski writes: It's about the horrible error messages that one gets if things go wrong with HLists not depending on shapeless, so people can use whatever version of shapeless that they want to it's totally possible to build a HList based version of those methods and give it to people as a library, ...


1

It's just a (distributed) job you can do asynchronous. When new data for the user comes in add it to the task queue. Detect previous jobs and prevent duplicated work When the previous job of that user is still there then remove the old one and place a new one. Or add the new data to the existing one. Depending on how you want to deal with this. Scale ...


Only top voted, non community-wiki answers of a minimum length are eligible