We have a system where we require all requests pertaining to a given
user-id be processed in order and by the same actor. For example : if we
get requests for userid - u1,u2,u3,u1,u4,u5,u5 in that order then the
requests for user-id u1 must always go to the same actor so that they can
processed
You should read up on cluster sharding:
http://doc.akka.io/docs/akka/current/scala/cluster-sharding.html
Such "to the same Actor, given an identifier" is exactly what it is designed
for.
--
Cheers,
Konrad 'ktoso’ Malawski
Akka @ Typesafe
On 28 November 2015 at 11:59:52, Karthik Deivasigamani (
You can use kafka to send messages do multiple akka stream consumers. Kafka
is a pub subs infrastructure. It can balance load between multiple
consumers and has high performance.
http://kafka.apache.org/
Basically you define a topic where messages are insert into and consumed.
One topic has N p
One thing you can look into is using the EventBus to send "domain events"
between top-level actors. Apparently top-level actors (i.e. created with
system.actorOf rather than context.actorOf) are more expensive so you don't
want zillions of them, but I think a handful of loosely-coupled components
i
I am currently modeling a PersistentFSM actor and humbly ask for guidance.
Suppose, we write a name to a database in the state "InProcess". Having
successfully committed to the database, we would like the state machine to
change its state to "Closed".
What if we manage to write to the database,
> On 28 Nov 2015, at 18:47, Richard Rodseth wrote:
>
> One thing you can look into is using the EventBus to send "domain events"
> between top-level actors. Apparently top-level actors (i.e. created with
> system.actorOf rather than context.actorOf) are more expensive
Really? Could you elabora
Thanks Konard
> On Nov 28, 2015, at 3:47 AM, Konrad Malawski
> wrote:
>
> You should read up on cluster sharding:
> http://doc.akka.io/docs/akka/current/scala/cluster-sharding.html
>
> Such "to the same Actor, given an identifier" is exactly what it is designed
> for.
>
> --
> Cheers,
> K
Oh, sorry, I thought I remembered reading that in the docs, but perhaps it
was just the cost of an actor system vs an actor.
Hopefully my advice was OK regardless :)
On Sat, Nov 28, 2015 at 1:03 PM, Heiko Seeberger wrote:
> On 28 Nov 2015, at 18:47, Richard Rodseth wrote:
>
> One thing you can
> On 29 Nov 2015, at 01:55, Richard Rodseth wrote:
>
> Oh, sorry, I thought I remembered reading that in the docs, but perhaps it
> was just the cost of an actor system vs an actor.
Ah, yes.
> Hopefully my advice was OK regardless :)
I agree with you. Although I go for a single top-level acto