Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 14 19:13
    hwanders commented #4096
  • Dec 14 13:05
    IgorFedchenko commented #4085
  • Dec 14 03:08
    hhko commented #4094
  • Dec 13 21:37
    Aaronontheweb commented #4085
  • Dec 13 20:28
    IgorFedchenko commented #4085
  • Dec 13 20:27
    IgorFedchenko commented #4085
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb milestoned #4096
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb opened #4096
  • Dec 13 10:41
    peirens-bart opened #4095
  • Dec 13 08:37
    Aaronontheweb synchronize #4071
  • Dec 13 08:13
    jiyeongj opened #4094
  • Dec 12 15:42
    Aaronontheweb synchronize #4086
  • Dec 12 15:42
    Aaronontheweb closed #4083
  • Dec 12 15:42

    Aaronontheweb on dev

    Fix #4083 - Endpoint receive bu… (compare)

  • Dec 12 15:42
    Aaronontheweb closed #4089
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
Nikita Tsukanov
@kekekeks
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
Any plans of publishing it as NuGet package?
Bartosz Sypytkowski
@Horusiath
I think, that this issue should be solved in scope of Akka.Cluster.Sharding plugin, when it comes out
my solution is good for copy/pasting (all code from repo is MIT-licensed) or to be described as a design pattern, but I think it's not sufficient and configurable enought to have it's own NuGet package
David Smith
@smalldave
@annymsMthd problems with the multi-node testing? not got far with the documentation I'm afraid
Roman Golenok
@shersh
Hi all. What if I need to create push-notification backend with different push services (WinPhone, APS, Android service, etc.). So what will be better:
  • Have coordinator, that have refs to workers and each worker have refs to actors which implements own service deliver
  • Have coordinator, that have refs to specified Actors routers that implements service.
    ?
Nikita Tsukanov
@kekekeks
Just use PushSharp, it already has that functionality
It doesn't actually have built-in worker support, but the first variant can be easily implemented with it
Roman Golenok
@shersh
@kekekeks thanks, I did see that project. My question is just for self-learning
Joshua Benjamin
@annymsMthd
@smalldave About running the Node tests in an AppDomain instead of starting a new process for each
Joshua Benjamin
@annymsMthd
@smalldave @Aaronontheweb My local branch now uses AppDomain for the individual nodes in multinode tests and i can debug the process without additional addons. Xunit actually does this under the covers when it runs a test suite. It has helped me spot a few race conditions going on. I am also seeing an issue with the ClusterDeathWatchSpec though. The node that was downed by the leader isn't recognizing that it itself is down and therefore isn't shutting down.
Nikita Tsukanov
@kekekeks
Dumb question. How does Akka.Persistence deal with renamed classes/namespaces?
I've seen "$type" in snapshots with FQ type names
Bartosz Sypytkowski
@Horusiath
It's pretty simple: it doesn't :)
That depends on used serializer (I don't remember how JSON.NET behaves in situation when $type field addresses non-existing type)
Roger Johansson
@rogeralsing
It would be pretty easy to add some resolver for that