Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 14:54
    IgorFedchenko synchronize #3973
  • 14:49
    IgorFedchenko synchronize #3973
  • Oct 22 21:12
    Aaronontheweb commented #4001
  • Oct 22 21:11

    Aaronontheweb on dev

    Added missing Persistence Testiā€¦ (compare)

  • Oct 22 21:11
    Aaronontheweb closed #4001
  • Oct 22 20:59
    sean-gilliam commented #3889
  • Oct 22 20:59
    sean-gilliam opened #4001
  • Oct 22 16:07
    spankr commented #3921
  • Oct 22 15:55
    Aaronontheweb labeled #3765
  • Oct 22 15:54
    Aaronontheweb labeled #3765
  • Oct 22 15:54
    Aaronontheweb milestoned #3765
  • Oct 22 15:53
    Aaronontheweb closed #3902
  • Oct 22 15:23
    Aaronontheweb commented #3921
  • Oct 22 15:11
    spankr commented #3921
  • Oct 22 15:05
    Aaronontheweb commented #3973
  • Oct 22 15:05
    Aaronontheweb commented #3973
  • Oct 22 15:02
    Aaronontheweb commented #4000
  • Oct 22 15:02
    Aaronontheweb milestoned #4000
  • Oct 22 15:02
    Aaronontheweb assigned #4000
  • Oct 22 15:01
    Aaronontheweb commented #3889
Arjen Smits
@Danthar
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.
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.
Rich Cox
@conejo
I have 2 questions: 1. Does Watch work with actors in the /temp hierarchy? 2. Do messages sent to an actor in the/temp hierarchy get sent to deadletters after they are killed?
Arjen Smits
@Danthar
@conejo 1: Theoretical yes. But why? 2: yes
Rich Cox
@conejo
@Danthar I'm using .Ask in a Nancy controller, and using a timespan for a timeout. I was trying to figure out how to get notified if the .Ask temp actor was killed or a message was sent to it after it was killed
Arjen Smits
@Danthar
a temp actor that gets created because of the Ask construct lives only as long, up untill the point it timeouts, or a response message is returned
watching it is pointless
its better to let the client simply retry if it timeouts
Rich Cox
@conejo
I agree on the retry, no problem there. However the controller action is not idempotent, if the result cant get returned to the client because it timed out, it needs to be undone
I made an actor to listen to the DeadLetter event stream, and subscribed it to the stream (typeof(DeadLetter)), but it's not receiving any
So, I've come up with an alternate strategy to use .Ask without a timeout (it will wait forever), and rely on ScheduleTellOnce to send a timed out notification
Chris G. Stevens
@cgstevens
What changes should I make to fix the following issue. My cluster of 10 members run fine with no unreachable issues. When I join the Cluster from my laptop which is on a different network segment and domain I get unreachable messages. Not all the time. But enough to cause disruption where other members can't join.
Bartosz Sypytkowski
@Horusiath
@conejo what's wrong with Ask + timeout?