Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 19:12
    IgorFedchenko commented #3998
  • 18:29
    Aaronontheweb commented #3998
  • 18:24
    Aaronontheweb opened #3998
  • 18:19

    Aaronontheweb on fix-readme-logo

    (compare)

  • 17:30
    Aaronontheweb milestoned #3973
  • 16:38
    jaydeboer opened #3997
  • 15:53
    Aaronontheweb synchronize #3973
  • 15:52

    dependabot-preview[bot] on dev

    Bump Microsoft.NET.Test.Sdk fro… (compare)

  • 15:52

    dependabot-preview[bot] on nuget

    (compare)

  • 15:52
    dependabot-preview[bot] closed #3996
  • 15:52
    Aaronontheweb commented #3996
  • 14:53
    Aaronontheweb commented #3973
  • 12:20
    IgorFedchenko commented #3973
  • 12:17
    IgorFedchenko commented #3973
  • 11:58
    IgorFedchenko synchronize #3973
  • 11:33
    IgorFedchenko commented #3973
  • 11:25
    IgorFedchenko synchronize #3973
  • 07:04
    dependabot-preview[bot] labeled #3996
  • 07:04
    dependabot-preview[bot] opened #3996
  • 07:04

    dependabot-preview[bot] on nuget

    Bump Microsoft.NET.Test.Sdk fro… (compare)

Ralf
@Ralf1108
i get the idea
Arjen Smits
@Danthar
:+1:
Ralf
@Ralf1108
i think it would be enough to just stash the passivate message when in the processing state
Arjen Smits
@Danthar
thats also possible.
Ralf
@Ralf1108
when processing is finished... unstash all moves original message first and then passivate message into mailbox
so normal workflow occurs
thx guys for helping out !!! :+1:
Arjen Smits
@Danthar
np
@maxcherednik passivate is a pattern used to reduce the amount of idle actors in your topology
imagine you have an actor per user in your system
and your routing messages to those user actors
you would have an coordinator as the parent of those user actors
which receives user messages and forwards them to the correct actor
then, depending on a strategy of your own making
for example a timeout
lets say that once a user actor has not seen a message in X amount of time
you want to stop it, so its state is unloaded from memory
the coordinator sends a passivate message to the user actor and starts buffering messages for that actor
actor stops, deathwatch notifies the coordinator
if the coordinator receives messages for that user again
it starts up the actor again
and forwards the message once the actor is up
this kind of pattern is very useful if you have a large pool of stateful actors which only occasionally receive messages.
Arjen Smits
@Danthar
Cluster Sharding uses passivate
Ralf
@Ralf1108
i like this pattern. it allows to manage thousands of actors and only the hotspot actors which are currently in use will be available in memory. similar to a garbage collector
Maxim Cherednik
@maxcherednik
@Danthar I see. Thx. Just never used it.
I am just wondering why don't I have this logic inside the Actor based on timeout - stop self...
then once new message arrives - the parent will just create it again and send the message to it
why do I need to use some kind of buffering or what so ever
Arjen Smits
@Danthar
because actor shutdown is async
the Terminate message is just that. A message
Maxim Cherednik
@maxcherednik
ah
right
Arjen Smits
@Danthar
so you want to buffer to account for race conditions
Maxim Cherednik
@maxcherednik
nowadays, I am trying to offload all the logic like this to the client :) Shutdown - async? ok that will skip the next message, client will retry on timeout :)
Arjen Smits
@Danthar
Thats a choice. Depending on your architecture it might be enough. Although when communicating across the network, if you want reliable delivery, you always end up with that kind of stuff
but the upside is. It can be abstracted away pretty easily
Maxim Cherednik
@maxcherednik
I see
Arjen Smits
@Danthar
"with that kind of stuff" i mean the thing you mentioned. Namely implement retries client side
Maxim Cherednik
@maxcherednik
btw do you always do this?
Arjen Smits
@Danthar
nope
Dont always need guarenteed delivery
And it depends on what your doing
Maxim Cherednik
@maxcherednik
it's kind of a boiler plate code... which you need to implement on every request response
of course if it's a UI call.... I will ask UI guys to timeout and push user to request it again
Jose Carlos Marquez
@oeaoaueaa
hi, whats the approach for a cluster of servers with a "flaky" network connection where some of the nodes are marked as Unreachable? should those nodes restart themselves? if so, how do they know?
Francis Paulin
@paulinfrancis

I've got two console apps that both connect successfully to lighthouse to join a cluster. I would like to publish messages from actors in one console app to actors in the other.

In the "from" console app

var mediator = DistributedPubSub.Get(_actorSystem).Mediator;
mediator.Tell(new ClusterClient.Publish("topic-foo", "my message"));

In an actor in the "to" console app

public RaspberryPiActor()
{
    var mediator = DistributedPubSub.Get(Context.System).Mediator;
    mediator.Tell(new Subscribe("topic-foo", Self));
    Receive<SubscribeAck>(_ => Become(Subscribed));
}

private void Subscribed()
{
    Receive<string>(m =>
    {
        Console.WriteLine(m);
    });
}

Am I doing something that is evidently wrong?

Francis Paulin
@paulinfrancis
All the messages go straight to dead letters.
Jose Carlos Marquez
@oeaoaueaa
what type is the result of: new ClusterClient.Publish("topic-foo", "my message")?
from what I understand, that is the message that is being sent