Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 07 11:49
    IgorFedchenko commented #4085
  • Dec 07 10:31
    IgorFedchenko commented #4085
  • Dec 07 08:36
    IgorFedchenko commented #4085
  • Dec 06 20:57
    IgorFedchenko commented #4085
  • Dec 06 20:32
    IgorFedchenko commented #4085
  • Dec 06 20:01
    IgorFedchenko commented #4085
  • Dec 06 19:55
    IgorFedchenko commented #4085
  • Dec 06 16:22
    Aaronontheweb labeled #3997
  • Dec 06 16:22
    Aaronontheweb closed #3997
  • Dec 06 16:20
    IgorFedchenko commented #3997
  • Dec 06 16:08
    IgorFedchenko commented #4085
  • Dec 06 15:50
    Aaronontheweb assigned #4085
  • Dec 06 15:50
    Aaronontheweb labeled #4085
  • Dec 06 15:50
    Aaronontheweb labeled #4085
  • Dec 06 15:49
    Aaronontheweb closed #4032
  • Dec 06 14:58
    IgorFedchenko commented #4032
  • Dec 06 14:57
    IgorFedchenko opened #4085
  • Dec 05 17:21
    Aaronontheweb synchronize #4079
  • Dec 05 17:20
    Aaronontheweb labeled #4084
  • Dec 05 17:20
    Aaronontheweb labeled #4084
Jose Carlos Marquez
@oeaoaueaa
no errors or warns
Jose Carlos Marquez
@oeaoaueaa
if the cluster is always meant to have the same number of nodes, and the services stop/leave the cluster when upgraded is there any need of downing provider?
Bartosz Sypytkowski
@Horusiath
if you're able to guarantee that neither your network nor your server will ever fail ;)
Jose Carlos Marquez
@oeaoaueaa
I know that is not a good solution, but worst case scenario, will need to restart lighthouse to "create" a new cluster right?
by they way, I have 3 instances of lighthouse, is that a bad practice?
Bartosz Sypytkowski
@Horusiath
no, lighthouse is just ordinary actor system. if you turn it down, your cluster will live anyway
and having 3 of them is fine
Jose Carlos Marquez
@oeaoaueaa
what I have notice is that when lighthouse services are restarted they create a new cluster and then the other nodes have to be restarted too for them to join
Bartosz Sypytkowski
@Horusiath
yes, because in order to join the cluster, a node must know another node, that is already part of it. Since your lighthouse nodes are down (and probably other nodes have dynamic addresses) you cannot simply join the cluster, as known endpoints are lost. When lighthouse nodes will go up again, they don't know that cluster lives somewhere out there, so they will join the nodes they know about - themselves - forming a new cluster. Joining to self address is equivalent of establishing new cluster
Jose Carlos Marquez
@oeaoaueaa
mmm, the addresses are static, should I pace the deployment of lighthouses in a way they could rejoin the same cluster instance?
Bartosz Sypytkowski
@Horusiath
if you don't throw down all lighthouse nodes, this shouldn't be a problem - this is a reason, why it's good to have more than one node working as lighthouse, so in the case if it goes down for some reason, there is a still replacement with known address
Jose Carlos Marquez
@oeaoaueaa
just realized that if I restart one of the lighthouse nodes it tries to join but gets stuck rejoining too
Bartosz Sypytkowski
@Horusiath
try setup auto-down, also AFAIK issue may be an order in which seed nodes are defined. @Aaronontheweb any ideas?
Jose Carlos Marquez
@oeaoaueaa
is it wrong to have "self" in the seed nodes?
Bartosz Sypytkowski
@Horusiath
no, it should be ok. But the problem with hanging join may be caused by some of the unreachable nodes not being marked as down, but @Aaronontheweb would need to confirm that
Aaron Stannard
@Aaronontheweb
after taking a look at the cluster code
think I found an issue
gotta confirm a behavioral thing real quick
it's an easy fix if it is what I think it is
looks like this issue comes up when a JoinSeedNodes operation starts and the InitJoin doesn't get delivered right away at startup (possible when two nodes try to connect to each other immediately)
we have a reliable delivery mechanism set up for that InitJoin command
but I just realized that it may not be implemented correctly due to how ReceiveTimeout works :(
setting up a reproduction test for this will be.... fun
have to guarantee that a specific message gets dropped the first time around :p
Aaron Stannard
@Aaronontheweb
Opened #2584
Damian Reeves
@DamianReeves
In TestKit, is there a way for me to expect a spcific message type without caring what messages came before it?
I see I can expect a specific message instance with ExpectMessageAnyOf
is FishForMessage what I'm looking for?
John Nicholas
@MrTortoise
lo, hows akka with .net core? can i do a local actor system in it?
simply want to prove it to a collegue pulling stuff from event store and wanging it into elastic
Arjen Smits
@Danthar
@MrTortoise .net core support is coming, soonish. If you scroll up you can find some people who have already worked with the stuff thats in the current dev branch. And we have the nightlies you can use.
John Nicholas
@MrTortoise
@Danthar thanks. will mooch
Graham Ambrose
@gambrose
@DamianReeves you can set an IgnoreMessages function to ignore any messages that you are not interested in, then ExpectMsg the message you want. This is what I do but... there maybe a better way.
Nick Chamberlain
@heynickc
@DamianReeves FishForMessage is also a viable option:
[Fact]
public void Expect_message_after_a_few()
{
    var actor = Sys.ActorOf(Props.Create(() => new EchoActor()));
    var probe = CreateTestProbe();
    actor.Tell("Yo!", probe.Ref);
    actor.Tell("Hey!", probe.Ref);
    actor.Tell("Wasup!", probe.Ref);
    actor.Tell("Hello!", probe.Ref);
    actor.Tell("Nevermind...", probe.Ref);

    probe.FishForMessage(msg => (string) msg == "Nevermind...");
}
Weston
@ronnyek
so I am interested in having akka.net handle tcp listening, taking the inbound messages and treating them as reactive streams
is the examples with the telnet listener technically akka.io stuff?
Bartosz Sypytkowski
@Horusiath
@ronnyek there's a simple example which uses akka.io actors. But once we fix everything related to akkadotnet/akka.net#2405 I think, that streams will be a much better approach
Weston
@ronnyek
will streams be able to listen on tcp or websockets or anything like that?
I thought streams solved different problems
any eta on 1.2?
months
ballpark
weeks
quarters =)
Deniz İrgin
@Blind-Striker
or ... When it’s done :P
Weston
@ronnyek
I realize its done when its done, but I dont know if I need to just wait for that because its around the corner
or if its a long ways off I need to investigate other stuffs
Ricky Blankenaufulland
@ZoolWay
Hi! Wanted to hear if you have situation where you need a class/recordtype which is mutating (changing state) and nearly the same class as immutable to send it through Akka messages. If I encounter this, is it a code smell, an anti-pattern? If not, how do you name both? Customer and CustomerMutating? CustomerImmutable and Customer? CustomerFrozenand CustomerState?
Deniz İrgin
@Blind-Striker
I just quoted from Blizzard :) we have similar issue too and waiting for 1.2
@ronnyek