Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 13:55
    Aaronontheweb commented #3811
  • 13:53
    Aaronontheweb commented #3811
  • 13:48
    Zetanova commented #3811
  • 13:21
    Aaronontheweb commented #3811
  • 12:15
    PetrPejcel opened #3917
  • 09:56
    Zetanova commented #3903
  • 09:42
    Zetanova commented #3811
  • 09:38
    Zetanova commented #3811
  • 09:37
    Zetanova commented #3811
  • 08:37
    Pzixel commented #3908
  • 08:20
    Zetanova synchronize #3916
  • 08:13
    Horusiath commented #3908
  • 08:12
    Horusiath commented #3908
  • 08:11
    Horusiath commented #3908
  • 07:58
    Horusiath commented #3284
  • 07:56
    Horusiath commented #3284
  • 07:32
    ismaelhamed commented #3284
  • 07:24
    Zetanova opened #3916
  • Sep 16 15:35
    Aaronontheweb commented #3284
  • Sep 16 07:55
    ismaelhamed commented #3284
Arjen Smits
@Danthar
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
Francis Paulin
@paulinfrancis
blob
Jose Carlos Marquez
@oeaoaueaa
I think you might be receiving a message of type "Publish", try Receive<Publish>(p => ....) instead
Francis Paulin
@paulinfrancis
No luck I'm afraid, but thanks for the suggestions!
Tried ReceiveAny too, just to be on the safe side
but it never hits the method
Arjen Smits
@Danthar
@paulinfrancis you are using the wrong Publish message
you should use the Akka.Cluster.Tools.PublishSubscribe.Publish message type
Sean Farrow
@SeanFarrow
Hi, I'm in a situation where I'm converting code to use actors for fault tolerance. I have a method that returns a stream, can messages return streams, or should I convert this to a byte array?
Bartosz Sypytkowski
@Horusiath
@SeanFarrow in general messages shouldn't use any disposable resources
Sean Farrow
@SeanFarrow
Hi, thanks, I'll convert the stream to a byte array then.