Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 14:40
    cptjazz synchronize #3974
  • 14:07
    cptjazz opened #3974
  • 08:30
    ismaelhamed commented #3937
  • Oct 12 15:50
    IrvinDominin opened #127
  • Oct 11 18:21
    Aaronontheweb commented #3973
  • Oct 11 18:20
    Aaronontheweb commented #3937
  • Oct 11 18:16
    Zetanova commented #3937
  • Oct 11 18:11
    Zetanova commented #3937
  • Oct 11 15:09
    Aaronontheweb commented #3937
  • Oct 11 15:08
    Aaronontheweb commented #3937
  • Oct 11 14:36
    Aaronontheweb commented #3973
  • Oct 11 01:00
    Horusiath commented #3057
  • Oct 10 20:02
    IgorFedchenko synchronize #3973
  • Oct 10 19:59
    IgorFedchenko synchronize #3973
  • Oct 10 19:58
    IgorFedchenko commented #3973
  • Oct 10 19:53
    IgorFedchenko opened #3973
  • Oct 10 14:04
    stijnherreman commented #3057
  • Oct 10 13:54
    Aaronontheweb commented #3970
  • Oct 10 13:54
    Aaronontheweb synchronize #3970
  • Oct 10 10:10
    Zetanova commented #3937
Roger Johansson
@rogeralsing
ah you want to "intercept" the path and then start actors that arent started, right?
Natan Vivo
@nvivo
Exactly that = use /path/to/manyactors/*
Nikita Tsukanov
@kekekeks
Yup
Roger Johansson
@rogeralsing
like a proxy
Nikita Tsukanov
@kekekeks
exactly
If you have, like, 1KK entities it would take a lot of time to load them from the storage
Roger Johansson
@rogeralsing
imo, easiest way, make a proxy that acts like the consistent hash router. but with the ability to start actors also
all messages goes to the same actor, and then use a property of the messages to identify what child to route to
Natan Vivo
@nvivo
This looks like the concept from orleans right?
Nikita Tsukanov
@kekekeks
So I'm stuck with old pattern of having ISmthManager that asks you for an id of that something in every call
meh
Quite kills the idea of just passing ActorRef around
Natan Vivo
@nvivo
I think you can do that with rogers idea
Ask a single actor for a message that contains an actorref
Let that single actor give you the reference somehow
Nikita Tsukanov
@kekekeks
And then be unable to unload that actor after inactivity timeout
but might just work in most cases
Since having an actor is cheap anyway
Natan Vivo
@nvivo
You can unload with SetTimeout and watch in the parent
Roger Johansson
@rogeralsing
Akka does not support the concept of virtual actors, we follow the JVM impl, they are looking into that on their side.. but as of now, there is no "on demand" activation of actors
Nikita Tsukanov
@kekekeks
Yup. Ask the parent for the reference, timeout expired, actor died, ActorRef is void
So these "ondemand" actors should live forever
Is it actually a good idea to have an actor for every entity in the system?
Natan Vivo
@nvivo
This is the orleans concept, akka is different. But both can achieve similar results. Looks like you want a specific solution, not a specific goal
Nikita Tsukanov
@kekekeks
Or just go with instances of UserManagerActor routed via consistent hash
Roger Johansson
@rogeralsing
depends on its responsibillities, if the actor is a heart beat creator for a heart machine, i'd say yes :) if it's a business entity / aggregate root, then no
Natan Vivo
@nvivo
Honestly I have a hard time to see the benefit of the virtual actor model for regular services.
Nikita Tsukanov
@kekekeks
I want to try event sourcing, so I'll need to have a PersistentActor for everything
just not sure that it should be exposed to the system or just incapsulated inside the parent that manages its lifetime
Natan Vivo
@nvivo
You don't necessarily need every entity of your system to be a persistent actor to do event sourcing, that's the point
This is a design choice
Nikita Tsukanov
@kekekeks
If entities are incapsulated inside SmthManagerActor it's just implementation detail.
Hm. It's actually not a "virtual actor" it's just something like url rewriting
Roger Johansson
@rogeralsing
There is the concept of Virtual Containers in Akka. the RemoteDaemon uses that for remote deployed actors, that pretty much do what you want.. but youd have to do all the plumbing yourself to implement a custom container for that.. but a good start is to look at the RemoteDaemon
Nikita Tsukanov
@kekekeks
wow
thanks
Roger Johansson
@rogeralsing
but this is way down in the dark dungeons of akka. not user facing standard api
Nikita Tsukanov
@kekekeks
I might just stick with something that wraps a message into another (containing path information) and passes it to a standard ActorRef
Shouldn't be that hard
Natan Vivo
@nvivo
This looks like one of those cases where it's better to understand "how should I do this in Akka" then trying to make akka match your mind model. But it's a nice exercise..
Nikita Tsukanov
@kekekeks
It's kinda hard after you had a system that used AMQP's topic exchanges for the same thing )
Nikita Tsukanov
@kekekeks
Well, having a bunch of SmthManagerActor routed with consistent hash is much more cluster-friendly
So exposing an ActorRef to underlying actors is probably a bad idea
Bartosz Sypytkowski
@Horusiath
@kekekeks take a look here - I think, I've implemented there what you want
you have concept of AggregateRoots accessed indirectly by AggregateCoordinator actors
coordinator works similiar to the consisent hash router, but it's able to manage lifecycle of it's children
Nikita Tsukanov
@kekekeks
And coordinators themselves can be routed via consistent hash
looks great
Bartosz Sypytkowski
@Horusiath
  • if there is a message addressed to persistent actor which doesn't occupy memory it becomes recovered from persistent storage
  • also when children count overcomes specified threshold, some of them become harvested/killed (since their state is already persisted)
Nikita Tsukanov
@kekekeks
Exactly what I'm looking for