These are chat archives for akkadotnet/akka.net

17th
Aug 2016
Aaron Stannard
@Aaronontheweb
Aug 17 2016 00:33
IPV6 support is such a damn head ache
haven't verified this yet but I have a hunch our Docker containers may not support it out of the box
Aaron Stannard
@Aaronontheweb
Aug 17 2016 00:40
between working around that and Mono bugs like this one https://bugzilla.xamarin.com/show_bug.cgi?id=35536 it makes it an adventure to get the test suite to pass
Ricky Blankenaufulland
@ZoolWay
Aug 17 2016 07:35
@Horusiath Thanks for you response from last week. In that case I will no longer fight JSON but try to stick to Wire. It just misses information on what could not be serialized/deserialized when something goes wrong.
Is there a possibility to get more information about the actor behind an actor path? Like which type is it so I can check from which assembly the actor class is coming from?
Bartosz Sypytkowski
@Horusiath
Aug 17 2016 07:39
@ZoolWay this info is not directly bound to actor paths. For example actor behind a path may come from an assembly unknown to the requester.
Ricky Blankenaufulland
@ZoolWay
Aug 17 2016 07:39
Sure, in that case it would not work.
I might need to register this information in some way then.
Bartosz Sypytkowski
@Horusiath
Aug 17 2016 07:39
if you have local IActorRef, there is a way to dig into actor type with reflection
i think, the easiest way is to include some info about type (i.e. type name) into actor's name
Ricky Blankenaufulland
@ZoolWay
Aug 17 2016 07:42
To be a bit more specific, I have like a plugin system and want the core to know which plugin has send the message because it should use different context data depending on that. The same time I would like to avoid having a "RequestingPlugin" property in all those messages. Another way might be that all plugin actors are children (or grandchildren) of some plugin master actor which can be detected by looking at the path,.
arnold-pinto
@arnold-pinto
Aug 17 2016 10:36

I'm trying out a very basic cluster example. 1 lighthouse node and a crawl service node from the Petabridge webcrawler GitHub repo. If I start both the nodes, they start up and join the cluster - I get the welcome message etc. Now if I kill the lighthouse process to simulate a failure, I start seeing dead letter notifications - which is expected. However, even when I restart the lighthouse node the crawl service node is unable to contact the seed node and displays the following message.

[WARNING][8/17/2016 10:27:26 AM][Thread 0013][[akka://webcrawler/system/cluster/
core/daemon#1297225546]] Cluster Node [akka.tcp://webcrawler@127.0.0.1:19384] -
Marking node(s) as UNREACHABLE [Member(address = akka.tcp://webcrawler@127.0.0.1
:4053, status = Up, role=[lighthouse], upNumber=1)]. Node roles [crawler]

[INFO][8/17/2016 10:27:45 AM][Thread 0011][[akka://webcrawler/system/cluster/cor
e/daemon#1297225546]] Leader can currently not perform its duties, reachability
status: [akka.tcp://webcrawler@127.0.0.1:19384 -> UniqueAddress: (akka.tcp://web
crawler@127.0.0.1:4053, 664522366): Unreachable [Unreachable] (1), ], member sta
tus: [$akka.tcp://webcrawler@127.0.0.1:4053 $Up seen=$False, $akka.tcp://webcraw
ler@127.0.0.1:19384 $Up seen=$True]

Could someone explain why the nodes are unable to form a cluster after restarting the seed node? Does it also mean that if all the seed nodes crash the entire cluster needs to be restarted?

Bartosz Sypytkowski
@Horusiath
Aug 17 2016 10:39
@arnold-pinto problem here is that nodes have been marked as unreachable, but not downed (you can change that by specifying some time value in akka.cluster.auto-down-unreachable-after HOCON or by downing nodes up manually).
arnold-pinto
@arnold-pinto
Aug 17 2016 10:49
@Horusiath Thanks for the quick reply. So to manually set a node as down, should I need to send a message to one of the Up nodes in the cluster and programmatically do something like Cluster(system).down(address) or are there any other alternatives?
Bartosz Sypytkowski
@Horusiath
Aug 17 2016 11:11

@arnold-pinto the basic algorithm looks like this:

  1. one of the actors subscribes to override PreStart() => Cluster(ContextSystem).Subscribe(new Type[]{typeof<ClusterEvent.IReachabilityEvent>}); (don't forget to unsubscribe in PostStop)
  2. setup receive handler for reachability events - there are two of them: ClusterEvent.UnreachableMember and ClusterEvent.ReachableMember
  3. when unreachable member has been detected, decide what to do next i.e. auto down strategy will schedule a downing request that will trigger after timeout configured in akka.cluster.auto-down-unreachable-after.
  4. if reachable member event has been triggered in the mean time, cancel previous action
  5. in case of auto-down strategy, when scheduled auto down event has been received and current actor lives on the leader node (which can be tracked by subscribing to ClusterEvent.LeaderChanged), use Cluster(Context.System).Down(unreachableNode) to down the node. Leader check condition is for making sure, that nodes won't flood themselves by trying to compete in sending down request for unreachable node.

But these steps are mostly for the case, when you want to implement your own downing strategy

if you want to count on the auto-down, you just need to set value in the HOCON config
@Aaronontheweb actually while writing the steps above I think, I'll know how to implement split brain resolvers ;)
arnold-pinto
@arnold-pinto
Aug 17 2016 12:24
Thanks @Horusiath. Will have a go and see how it works out.
Ricky Blankenaufulland
@ZoolWay
Aug 17 2016 12:30
Wow, @Horusiath , thanks for pointing to that setting. I implemented my own auto-down strategy which is basically the same just because I did not know / find out about that setting
MartinNiemandt
@MartinNiemandt
Aug 17 2016 13:20
Hi, Is this log message worth losing sleep over? address is now gated for 5000 ms. Reason is: [Akka.Remote.EndpointDisassociatedException: Disassociated
JoeCoJabba
@joecojabba
Aug 17 2016 14:20
MartinNiemandt
@MartinNiemandt
Aug 17 2016 14:24
@joecojabba Hahaha, well... thank you... I will read through that page.
Aaron Stannard
@Aaronontheweb
Aug 17 2016 14:52
@Horusiath aren't the split brain resolvers just implementations of the DowningProvider?
which will still have to support in Akka.Cluster
one of the things we skipped so we could get 1.1 out the door
Aaron Stannard
@Aaronontheweb
Aug 17 2016 15:04
I'm looking to add that feature soon-ish
I have some ideas for cloud-integrated downing providers
i.e. if you're running on Azure ARM, use those APIs to detect if an unreachable node was actually killed by Azure Management or not
can do the same for AWS, Service Fabric, Consul
and probably the Docker cluster stuff too
so if a node is really permanently offline
i.e. the VM was terminated or the Docker container was killed
that node will just be automatically removed
if the service management API can't be reached
the downing provider won't do anything
that way if you're running something like Consul and that VM restarts
it won't cause your cluster to go beserk
Ricky Blankenaufulland
@ZoolWay
Aug 17 2016 15:09
There are some cross cloud platform management tools / APIs out there which might be a nice idea to do some of that stuff. Not sure if applicable though
Aaron Stannard
@Aaronontheweb
Aug 17 2016 15:09
@ZoolWay it's applicable - the downing provider is a client of those APIs
err, "would be" a client of those APIs
Ricky Blankenaufulland
@ZoolWay
Aug 17 2016 15:11
question is if the single cloud providers would be needed then if you have one which can be able to rule them all (or most of them)
Aaron Stannard
@Aaronontheweb
Aug 17 2016 17:41
https://github.com/akkadotnet/akka.net/issues/2227#issuecomment-240485618 - cc @rogeralsing @Danthar @cconstantin @Horusiath @alexvaluyskiy @Silv3rcircl3 had issues like this before with Helios and other dependencies too. Should our NuSpec file start locking down dependencies to their major version numbers? (i.e. only Helios 2.x can be used, JSON.NET 9.x, etc...) ? I'd kind of hate to do that because of the shitstorm that could cause with a widely used dependency like JSON.NET or System.Collections.Immutable, but users do shoot themselves in the foot with upgrading to unsupported versions every now and then.
I'd rather have a few PEBKAC issues pop up on Github issues or the mailing list every now and then versus making Akka.NET totally unworkable for users who have to integrate it with something like ASP.NET for instance, which also depends on Json.net
Marc Piechura
@marcpiechura
Aug 17 2016 17:47
Yep, I did the same to block NUnit 3 for the NUnit 2 testkit package see https://github.com/akkadotnet/Akka.TestKit.Nunit/blob/dev/src/Akka.TestKit.NUnit/packages.config
Aaron Stannard
@Aaronontheweb
Aug 17 2016 17:47
in places like that it makes total sense
we should probably also update the XUnit 1 package to do that
whoops meant to cc @sean-gilliam on that earlier message too
Alex Valuyskiy
@alexvaluyskiy
Aug 17 2016 17:48
Xunit1 package could be redundant. Is someone use it?
Aaron Stannard
@Aaronontheweb
Aug 17 2016 17:49
legacy mostly
we were using it internally before XUnit2 was RTM-ed
Arjen Smits
@Danthar
Aug 17 2016 17:54
@Aaronontheweb Agreed on the not locking of versions. I dont mind the occasional github issue on that subject.
builds history as well. The people who search for issues will find them, and wont have to ask anew
Aaron Stannard
@Aaronontheweb
Aug 17 2016 22:26
so this is pretty fascinating... Helios on Mono, running inside a Docker container, is crushing the Windows / .NET 4.6.2 version running on Windows Server 2016
same underlying hardware
comparing benchmarks for current builds - weird; I had looked earlier and it looked like Mono / Windows were neck and neck
very odd
wonder if the issue might be that Windows Server is just running a lot more shit in the background
because it's Windows
Aaron Stannard
@Aaronontheweb
Aug 17 2016 22:36
nope, there's a real and noticeable performance difference between the two
the entire mono build process completes in under 25 minutes for Helios
the majority of that time is spent running benchmarks
it takes Windows 25 minutes for benchmarks, 7 running unit tests, and 30 - 60 seconds compiling
Mono does all of that in just 25
could also be that Windows Server 16, which is still in tech preview, has a ways to go yet
goes to show you though - the work the Mono team has put into 4.x, which is the branch that has taken advantage of CoreFx being OSSed
has really paid off
Corneliu
@corneliutusnea
Aug 17 2016 23:53
guys, is there a quick way to fire a message into the dead letters queue? e.g. I got a message, tried to process it but it's missing something so I want to end up in the dead letters (as if I wouldn't have processed it)