These are chat archives for akkadotnet/akka.net

20th
Dec 2016
Andrew Young
@ayoung
Dec 20 2016 00:28
Aaron Stannard
@Aaronontheweb
Dec 20 2016 00:28
LOL
that is amazing
who made that?
Andrew Young
@ayoung
Dec 20 2016 00:28
i have no idea.
do you know how much time i spend trying to make it all align?
Andrew Young
@ayoung
Dec 20 2016 00:34
looks like someone from India
to11mtm
@to11mtm
Dec 20 2016 00:52
omg awesome
Andrew Young
@ayoung
Dec 20 2016 04:10
Arjen Smits
@Danthar
Dec 20 2016 07:44
that is very nice
Arsene Tochemey GANDOTE
@Tochemey
Dec 20 2016 07:52
Hello Geeks. Can someone explain to me the existence of this property existenceConfirmed and addressTerminated in the Terminated message?
Sergey Prytkov
@Rattenkrieg
Dec 20 2016 08:00
Hi guys, can someone re-run this:
As far as I understand this test fails sometimes due to tight timing limits
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 08:04
@Rattenkrieg done
Sergey Prytkov
@Rattenkrieg
Dec 20 2016 08:04
thanks!
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 08:07
@Tochemey existenceConfirmed is true when terminated message was send directly by the terminated actor. addressTerminated is true when you were watching a remote actor on a cluster node, that has been marked as unreachable. So Actor itself may or may not be dead, but we cannot tell it for sure and we cannot communicate with it
Vagif Abilov
@object
Dec 20 2016 08:44
Tried to update Wire NuGet packages, and still get "Method not found: 'Void Wire.SerializerOptions..ctor". So we should stick with Wire 0.0.6 when using Akka.NET, right? That NuGet package is one year old though.
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 08:58
@object the latest one I've tried to use was 0.8.1 - it's also the latests with no license issues
Vagif Abilov
@object
Dec 20 2016 09:00
And it worked with Akka.NET 1.*? I just tried the latest one (0.8.2) and got the error above. Didn't try 0.8.1 but according to SemVer they should not be different when it comes to method signatures.
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 09:01
if you belive in semver, then yes :)
Vagif Abilov
@object
Dec 20 2016 09:02
OK, I'll try 0.8.1 then with a risk of ruining my belief in semver.
Hmm, this is what I am getting with 0.8.1:
System.Reflection.TargetInvocationException : Exception has been thrown by the target of an invocation.
----> System.Reflection.TargetInvocationException : Exception has been thrown by the target of an invocation.
----> System.MissingMethodException : Method not found: 'Void Wire.SerializerOptions..ctor(Boolean, System.Collections.Generic.IEnumerable1<Wire.Surrogate>, Boolean, System.Collections.Generic.IEnumerable1<Wire.Converters.ValueSerializerFactory>)'.
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at <StartupCode$TickSpec>.$TickSpec.createAction@212-1.Invoke()
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 09:05
nothing abnormal - as long as you don't enforce semver as part of your build process, don't count on it
lol
Vagif Abilov
@object
Dec 20 2016 09:06
So you are saying that Wire 0.8.1. works for you?
At least it's semver compliant for me :-)
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 09:07
well, I think I meant 0.7.1
;)
Vagif Abilov
@object
Dec 20 2016 09:07
Now we're talking!
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 09:07
btw. soon we'll probably release Hyperion - it's a Wire fork, we'll be using from now on
Vagif Abilov
@object
Dec 20 2016 09:08
I see, thanks.
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 09:09
At least I want to merge akkadotnet/Hyperion#9 before. Probably guys also have something with .NET core port, so we could publish both normal and .net core packages
Vagif Abilov
@object
Dec 20 2016 09:09
Nope, same exception with 0.7.1!
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 09:10
if you're using Akka.Serialization.Wire maybe that package is outdated
Vagif Abilov
@object
Dec 20 2016 09:10
Oh...
Yepp, will have a look at it.
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 09:10
because we use reference to Wire 0.7.1 inside of it
and I see, SerializerOptions are already known to it
Vagif Abilov
@object
Dec 20 2016 09:12
Yes, upgrading Akka.Serialization.Wire fixed it!
I will event try 0.8.1 now, as semver suggests :-)
Or should I stick to 0.7.1 until Hyperion is out?
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 09:16
no, 0.8.1 should be fine
Vagif Abilov
@object
Dec 20 2016 09:21
Thanks!
Alex Michel
@amichel
Dec 20 2016 11:23
hi, any example available on how to persist become/unbecome state and process stashed messages after recovery (particularly I need to recover in cluster sharding scenario after rebalancing)
Arsene Tochemey GANDOTE
@Tochemey
Dec 20 2016 13:53
Hello Geeks. Can we have an alpha-release of the Akka.NET Core build?
Because some of us have become addicted to it.
Darren Ford
@4deeptech
Dec 20 2016 18:29
I have some questions about clustering and actor deployment and configuration. I created a Gist https://gist.github.com/4deeptech/9a6416b980ba102a8e1c094d2ee2384f to show config context and have the questions in the comments of the .cs file. The questions revolve around deployment configuration on different nodes if a given node already has an actor defined. A Gist seemed easier to demonstrate with an area for comments.
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 18:47

@amichel if you're not using snapshots you can just change behavior using Become as part of state recovery. If you're using snapshots, then you can include current behavior i.e. as enum, and when snapshot offer will be loaded, just switch behavior depending on it. Other option would be to set receive method as delegate and persist it along with the state itself, but this require you to use serializer that is able to work with delegates (i.e. Wire/Hyperion should be ok).

Regarding stashed messages I don't know if there are any build in mechanics there - we could possibly make a PR for that. But since persisting messages themselves usually cripples performance, I think the easiest way here is to push stash content back to the shard. First thing, that came out to my head look like that:

// we need custom stop message (can be set in shard region)
// because PoisonPill will immediatelly terminate an actor
Command<CustomStop>(_ =>{
    var envelopes = Stash.ClearStash();
    foreach (var env in envelopes){
        /// retransmit messages back to myself using cluster sharding mechanics
        var shardId = Self.Path.Parent.Name;
        var entityId = Self.Path.Name;
        /// ShardEnvelope is used by shard region MessageExtractor implementation
        shardRegion.Tell(new ShardEnvelope(shardId, entityId, env.Message), env.Sender);
    }
});
@4deeptech each cluster node has a separate naming path - so /user/actorA on node 1 and /user/actorA on node 2 are two different paths
Philip Laureano
@philiplaureano
Dec 20 2016 20:25
Hmm. Does anyone know if Akka.NET's schedulers are preemptive or cooperative?
Aaron Stannard
@Aaronontheweb
Dec 20 2016 20:26
the actual scheduler for recurring tasks is just a hashed wheel timer
the dispatchers delegate the actual scheduling of mailbox runs down to the .NET thread pool or a dedicated thread pool
don't think either of those are pre-emptive
since there's no real concept of priority
Philip Laureano
@philiplaureano
Dec 20 2016 20:28
but would it be possible to make it preemptive if you could suspend threads?
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 20:28
@philiplaureano sure, it's possible to achieve
Philip Laureano
@philiplaureano
Dec 20 2016 20:28
Interesting
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 20:29
some tweaking in akka.net internals
on the other side - is there any preemptive scheduler solution in .NET?
Philip Laureano
@philiplaureano
Dec 20 2016 20:34
I don't know--I was about to mock up a preemptive scheduler to see if it's possible
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 20:34
Erlang can do that because of reduction counter, Haskell has something similar. But is yielding in fixed points (like Go system calls or TPL awaits) considered preemptive?
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 20:39
what I mean here is that preemptive scheduler would need some support from the compiler or VM itself
otherwise user could write some custom code, that would never set a point for scheduler to intercept execution
Philip Laureano
@philiplaureano
Dec 20 2016 20:44
Emitting the IL to add the necessary instructions isn't too difficult
I just need to wrap my head around the scheduling algorithm
Anyway, thanks for giving me a place to start :)
Bartosz Sypytkowski
@Horusiath
Dec 20 2016 20:54
you can always use roslyn :P
Arjen Smits
@Danthar
Dec 20 2016 21:33
@philiplaureano interesting thread on that topic: dotnet/orleans#694
Andrew Young
@ayoung
Dec 20 2016 23:32
i'm looking for ideas on how to run integration tests for a cluster
this obviously will involve an environment where we will have a bunch nodes running but how do you test the behavior of the entire cluster as a whole?
Aaron Stannard
@Aaronontheweb
Dec 20 2016 23:43
@ayoung multi-node testkit is how we do it
you assert the behavior of the cluster from the point of view of individual nodes
so when X happens in a cluster
nodes A B and C expect X
but nodes E and F expect Y, because they're on the other side of a network partition
things like that
Andrew Young
@ayoung
Dec 20 2016 23:44
do you typically just wait a set number of time before expecting?
also, what if you want to do system tests from a cluster across a http boundaries?