These are chat archives for akkadotnet/akka.net

6th
Apr 2017
Jeff Pang
@jeff-pang
Apr 06 2017 02:24
@Blind-Striker Yeah, same, I can't find akka core in myget. Thanks for the branch. I'll do my own compilation too
Nick Chamberlain
@heynickc
Apr 06 2017 13:09
@webeoutrascoisas so are you having issues using ActorSelection to get to the TestProbe? Here's what I was thinking:
[Fact]
public void Should_probe_replace_actor_selection_and_forward()
{
    var testProbe = CreateTestProbe("FindMeWithSelectionProbe");
    var actor = Sys.ActorOf(Props.Create(() => new FindMeWithSelectionActor()), "FindMeWithSelection");
    var selection = Sys.ActorSelection(testProbe.Ref.Path);
    selection.Tell("Hi!");
    testProbe.ExpectMsg("Hi!");
    testProbe.Forward(actor);
}
Franky Ostyn
@FOstyn
Apr 06 2017 14:11

Hi all,
a NLog question: with NLog is it possible to define 2 or more different logfiles.
<rules>
<logger name="AkkaLog" minlevel="Debug" writeTo="logfile1" />
<logger name="myLogFile" minlevel="Debug" writeTo="logfile2" />
</rules>

Using the same config file for Akka doesn't work, nothing is logged from Akka, I think Akka expects the name = "" like:
<rules>
<logger name="
" minlevel="Debug" writeTo="logfile1" />
</rules>

Is it possible to define in HOCON the name of the logfile for Akka ?

Great, the "" must be "*"
Jose Carlos Marquez
@oeaoaueaa
Apr 06 2017 14:29
Is there any limit in the amount of nodes a cluster can have? when I deploy my services there is only one being left out, permanently joining (we have 21 nodes in the test environment)
Aaron Stannard
@Aaronontheweb
Apr 06 2017 14:30
@oeaoaueaa no limit that I know of
Jose Carlos Marquez
@oeaoaueaa
Apr 06 2017 14:31
ok, any logging line or configuration I should look at?
Aaron Stannard
@Aaronontheweb
Apr 06 2017 14:32
just sent you a private message asking for some logs from the affected node
that would be super helpful if you could send those my way
Bartosz Sypytkowski
@Horusiath
Apr 06 2017 14:33
@oeaoaueaa lower bound doesn't exists, however it's always better to have 2-3 nodes just in case. Upper bound: hard to tell, I guess no one tested this on .NET platform. On JVM they reached 2400 node cluster, but that test was couple years ago and probably now they can do better
Jose Carlos Marquez
@oeaoaueaa
Apr 06 2017 14:46
21 should be nothing then, I was thinking that it could be something related to configuration because there are two services in the same machine that is always the last to be deployed and is one of those two that gets stuck joining
Bartosz Sypytkowski
@Horusiath
Apr 06 2017 14:48
there may be many reasons, starting from configuration ending on the content of dlls and how many nodes at once you're trying to join
do you get any error messages?
i.e. by default no downing provider is configured so you may want to configure akka.cluster.auto-down-unreachable-after = <X>sec to be able to mark stale unreachable nodes to be marked as dead
Jose Carlos Marquez
@oeaoaueaa
Apr 06 2017 14:51
no errors or warns
Jose Carlos Marquez
@oeaoaueaa
Apr 06 2017 15:03
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
Apr 06 2017 15:05
if you're able to guarantee that neither your network nor your server will ever fail ;)
Jose Carlos Marquez
@oeaoaueaa
Apr 06 2017 15:07
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
Apr 06 2017 15:08
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
Apr 06 2017 15:09
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
Apr 06 2017 15:11
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
Apr 06 2017 15:13
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
Apr 06 2017 15:15
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
Apr 06 2017 15:36
just realized that if I restart one of the lighthouse nodes it tries to join but gets stuck rejoining too
Bartosz Sypytkowski
@Horusiath
Apr 06 2017 15:37
try setup auto-down, also AFAIK issue may be an order in which seed nodes are defined. @Aaronontheweb any ideas?
Jose Carlos Marquez
@oeaoaueaa
Apr 06 2017 15:39
is it wrong to have "self" in the seed nodes?
Bartosz Sypytkowski
@Horusiath
Apr 06 2017 15:41
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
Apr 06 2017 18:18
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
Apr 06 2017 18:31
Opened #2584
Damian Reeves
@DamianReeves
Apr 06 2017 22:24
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?