These are chat archives for akkadotnet/akka.net

19th
Aug 2018
Shukhrat Nekbaev
@snekbaev
Aug 19 2018 00:00
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
mwardm
@mwardm
Aug 19 2018 00:09
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!]
Shukhrat Nekbaev
@snekbaev
Aug 19 2018 00:37
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
mwardm
@mwardm
Aug 19 2018 08:06
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.
Lutando Ngqakaza
@Lutando
Aug 19 2018 10:38
@mwardm i just tried to throw an exception in an awaited method within ReceiveAsync, supervision kicked in, Maybe you had a special case?
Lutando Ngqakaza
@Lutando
Aug 19 2018 11:33
has anyone tried running multinode testkit on *nix?
Lutando Ngqakaza
@Lutando
Aug 19 2018 12:43
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
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=on
I 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
mwardm
@mwardm
Aug 19 2018 16:33
@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.
Bartosz Sypytkowski
@Horusiath
Aug 19 2018 18:34
@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.
Shukhrat Nekbaev
@snekbaev
Aug 19 2018 19:47
@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