Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 13:56
    to11mtm commented #4636
  • 12:02
    endeffects opened #4654
  • Dec 04 23:50
    Aaronontheweb commented #4636
  • Dec 04 23:34
    Aaronontheweb commented #4643
  • Dec 04 22:26
    motmot80 synchronize #4643
  • Dec 04 22:04
    Aaronontheweb commented #4636
  • Dec 04 21:36
    motmot80 commented #4643
  • Dec 04 21:04
    Aaronontheweb commented #4636
  • Dec 04 20:45
    motmot80 commented #4643
  • Dec 04 20:29
    Aaronontheweb commented #4636
  • Dec 04 14:51
    razvangoga commented #4215
  • Dec 04 13:27
    DanielDziubecki commented #29
  • Dec 04 00:07
    Zetanova commented #3663
  • Dec 04 00:04
    Zetanova opened #4653
  • Dec 03 21:15
    razvangoga synchronize #4652
  • Dec 03 21:15
    razvangoga closed #4644
  • Dec 03 20:57
    razvangoga commented #4215
  • Dec 03 20:56
    razvangoga synchronize #4652
  • Dec 03 20:41
    razvangoga commented #4215
  • Dec 03 20:29
    razvangoga commented #4215
AnchishkinAlex
@AnchishkinAlex
explore*
Aaron Stannard
@Aaronontheweb
wish I could, but it's part of the training materials we distribute to our customers
that being said, we do have all of these ones
the WebCrawler one for Akka.Cluster is probably the most relevant there
AnchishkinAlex
@AnchishkinAlex
Thanks! I saw Akka.NET Bootcamp, Chat Server Example but not this samples :smile:
Aaron Stannard
@Aaronontheweb
you're welcome!
AnchishkinAlex
@AnchishkinAlex
And I know about your post "When I should use Actor Selection?". Is this situation relevant, isn't it?
Aaron Stannard
@Aaronontheweb
yes it is
generally, IActorRef is going to be both more performant and flexible at run-time
since it has the benefit of location transparency and doesn't need to be "resolved"
but ActorSelection is ideal in situations where you don't have a reference to an actor yet but still need to contact it
and you know roughly where it is in the hierarchy
most people build their actor hierarchies top-down
where the top level actors filter messages down to their children and so forth
so by convention, most developers treat their top level actors like "public APIs"
therefore, it's usually safe to select those and trust that your message will eventually be routed to the correct concrete actor who will actually do the processing
and that actor will send you a reply back directly
you can also do some cool stuff with wildcard actor selections
i.e. akka.tcp://mysys@127.0.0.1:9110/user/myParent/*/myGrandChild
you can dynamically select all of the grand children of myParent named myGrandChild without knowing what the parent's name is
I used that to build our actor hierarchy visualizer in Petabridge.Cmd: https://cmd.petabridge.com/articles/commands/actor-commands.html#actor-hierarchy
AnchishkinAlex
@AnchishkinAlex
it's interesting
So well! We will try Actor Selection for this moment. Thanks again! All the best! :smile:
vicosoft4real
@vicosoft4real
Can some please explain the philosophy behind this Cluster Sharding shenanigans.
Aaron Stannard
@Aaronontheweb
@vicosoft4real Cluster.Sharding tries to guarantee that there is exactly one copy of a given entity inside your cluster at any given time
where each entity is represented as its own actor
it has tooling in place to do things such as redistribute entities when the cluster changes
buffer messages being sent to a given entity while it's being moved
and a placement algorithm for figuring out where it should spawn new ones
each entity should, ideally, persist its state somewhere
vicosoft4real
@vicosoft4real
sounds good
Aaron Stannard
@Aaronontheweb
so in the event that the entity passivates (shuts down after a period of inactivity) and needs to be recreated in the future
vicosoft4real
@vicosoft4real
but we cannot have full control of the created entity/actor
Aaron Stannard
@Aaronontheweb
or in the event that the entity gets moved
it can recover its previous state
you can define the Props that get used to spawn ALL entity actors
vicosoft4real
@vicosoft4real
ok
Aaron Stannard
@Aaronontheweb
but no, you don't have any control over how that actor is created
it's created lazily
when someone sends a message to the ShardRegion or ShardRegionProxy
and the sharding system uses a MessageExtractor to pull the entityId from the message
if an entity doesn't exist with that entityId yetr
it will be created
essentially it's doing the same thing the child-per-entity pattern does
vicosoft4real
@vicosoft4real
ok
vicosoft4real
@vicosoft4real
to actually have full control over an actor , like managing the state, persisting message to external DB, Cluster sharding may not be best approach.
Aaron Stannard
@Aaronontheweb
you can still use cluster.sharding for that
the actor can control its own life cycle
its just that the actor can be moved if a new node joins the cluster that can host shards