actually, got a question about ReceiveAsync. How does one change the behaviour via Become? It's crashing with ActorContext not being available. If context is captured, however, it doesn't seem to have the same overload
Sorry - never did that. ( By "captured", you mean stored in a local variable at the start of the method prior to any awaiting and referenced via that variable later? I can see how a runtime error might possibly result, but not how the overload wouldn't be available. )
[Night!]
var context = Context;
async,ConfigureAwait(false) stuff;
context.Become() <-- doesn't have the same overload as just Become
for now moved the
Become before async calls
Oh, that'd be because the overload is static and can't be referenced through an instance variable, would it? (Java lets you, as I recall!
Think I might have also seen something about this changing in c# in some way, actually.
@mwardm i just tried to throw an exception in an awaited method within
ReceiveAsync, supervision kicked in, Maybe you had a special case?
has anyone tried running multinode testkit on *nix?
Tried running the multinode tests on the repo and im getting this, I am quite sure of the dll path there (I am on mac)
with the command in term
I am getting
with the command in term
dotnet run --project Akka.MultiNodeTestRunner.csproj -f netcoreapp1.1 "/Users/lutando/Workspace/Akka/akka.net/src/core/Akka.Cluster.Tests.MultiNode/bin/Debug/netcoreapp1.1/Akka.Cluster.Tests.MultiNode.dll" -Dmultinode.enable-filesink=onI am getting
[INFO][08/19/2018 12:42:13][Thread 0010][akka://TestRunnerLogging/deadLetters] Message Bound from akka://TestRunnerLogging/system/IO-TCP/$a to akka://TestRunnerLogging/deadLetters was not delivered. 1 dead letters encountered.
Starting test A_leader_that_is_leaving_must_be_moved_to_leaving_then_exiting_then_removed_then_be_shut_down_and_then_a_new_leader_should_be_elected
[RUNNER][08/19/2018 12:42:13][INFO][Akka.MultiNodeTestRunner]: Starting test A_leader_that_is_leaving_must_be_moved_to_leaving_then_exiting_then_removed_then_be_shut_down_and_then_a_new_leader_should_be_elected
[RUNNER][08/19/2018]: Beginning spec Akka.Cluster.Tests.MultiNode.LeaderLeavingSpecConfig+LeaderLeavingSpec.A_leader_that_is_leaving_must_be_moved_to_leaving_then_exiting_then_removed_then_be_shut_down_and_then_a_new_leader_should_be_elected on 3 nodes
Unhandled Exception: System.ComponentModel.Win32Exception: No such file or directory
at Interop.Sys.ForkAndExecProcess(String filename, String[] argv, String[] envp, String cwd, Boolean redirectStdin, Boolean redirectStdout, Boolean redirectStderr, Int32& lpChildPid, Int32& stdinFd, Int32& stdoutFd, Int32& stderrFd)
at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
at System.Diagnostics.Process.Start()
at Akka.MultiNodeTestRunner.Program.Main(String[] args) in /Users/lutando/Workspace/Akka/akka.net/src/core/Akka.MultiNodeTestRunner/Program.cs:line 311
@Lutando ReceiveAsync supervision also seems fine for me with my current code. Thought I'd posted about it here a year or more ago but can't see any details. (It's possible I was feeding an async void method to the normal Receive method - can't see more than that possibility from my code history.) Probably safe to ignore my earlier warnings then as long you're not coding like I was - apologies.
@snekbaev if I were you I'd first try to remove all of the
ConfigureAwait(false) stuff from the code and see if this changes something - Context is thread static variable, switching between Tasks execution contexts back and forth may cause weird behaviors over it. ConfigureAwait should be used with understanding, while now most tutorials promote to using it blindly in any scenario.
@Horusiath from the top of my head recommendation was to use ConfigureAwait(false) for libraries, without it thread context will be captured and restored, however, afaik, it has some perf benefits to have it with false and, afair, helps avoiding deadlocks. I use "false" in WebAPI projects by capturing required request values beforehand. I'm not sure what's the best practice for akka.net in that respect (regarding the synchronisation context), so was following the similar approach