These are chat archives for akkadotnet/akka.net

16th
Oct 2017
Thomas Denoréaz
@ThmX
Oct 16 2017 00:10
It is also worth mentioning, I tried adding a Context.Watch(...) on both TcpConnection but they are both still there
Jessie Wadman
@JessieWadman
Oct 16 2017 00:24
Looks like remoting (and clustering) breaks when communicating cross-platform using .NET base types like DateTimeOffset, List and Dictionary, etc. Consider when a Windows Forms application remotes to an actor system running on Linux built with .NET Core. The problem isn't with Akka.Remoting itself, but with the underlying serializers (both Newtonsoft.Json and Hyperion), because of the strict type naming configuration in Akka, resulting in the serializers not being able to resolve types between mscorlib.dll/System.Core.dll (on .NET 4.6) and System.Private.CoreLib.dll (.NET Core). Anyone already bumped into this problem and solved it? It's only a problem for BCL types, obviously, but you'd be surprised at how often you use List and Dictionary and DateTimeOffset :-)
Thomas Denoréaz
@ThmX
Oct 16 2017 09:09
Ok it was my bad, I found the problem. I'm still surprised though, as the message was not displayed as unhandled message. I was only handling Tcp.Closed and Tcp.PeerClosed and it was firing a Tcp.ErrorClosed, so now I'm directly handling Tcp.ConnectionClosed.
Robert Stiff
@uatec
Oct 16 2017 09:49
so here's a fun story
i have very valuable data in my FSM
and i just corrupted it
i am storing my state in redis and I can see that the "akka:persistence:snapshotssnapshot:myfsm" is intact, but the "akka:persistence:snapshotsjournal:persisted:myfsm" is corrupted
i have a back up of akka:persistence:snapshotsjournal:persisted:myfsm though, but it might not be insync with the current state of akka:persistence:snapshotssnapshot:myfsm
can anyone help me figure out how best to integrate these remaining bits of state?
Robert Stiff
@uatec
Oct 16 2017 10:16
phew, actually, my FSM had not persisted it's state, so the journal was corrupt, but removed the journal and reset back to 10 minutes ago
jalchr
@jalchr
Oct 16 2017 11:27

I'm trying to make the Akka.Persistence.AtLeastOnceDeliveryReceiveActor v1.3.1

                Deliver(commandRouter.Path,
                    messageId =>
                    new ReliableDeliveryEnvelope<StartJob>(startJob, messageId));

Where commandRouter is defined like this

            var commandRouter = ClusterSystem.ActorOf(Props.Empty.WithRouter(FromConfig.Instance), "tasker");

and has following hocon config:

/tasker {
                  router = consistent-hashing-group
                  routees.paths = ["/user/api"]
                  virtual-nodes-factor = 8
                  cluster {
                      enabled = on
                      max-nr-of-instances-per-node = 1
                      allow-local-routees = on
                      use-role = web
                  }

The message never reaches the destination actor. If I use an actor instead of a router, it works fine !

So this works
                Deliver(SystemActors.ApiMaster.Path,
                    messageId =>
                    new ReliableDeliveryEnvelope<StartJob>(startJob, messageId));
Robert Stiff
@uatec
Oct 16 2017 12:59
with things like that, i find that you have to create the router on every single node
that's definately the case with singletons
jalchr
@jalchr
Oct 16 2017 13:28
I think this is more like a bug
Bartosz Sypytkowski
@Horusiath
Oct 16 2017 13:56
@jalchr if you have a cluster group router, you're basically creating an endpoint on the local node, that will redirect all incoming messages to actors defined by routees.paths, living on an every node in the cluster having a configured role. This also means, that those actors (in your case /user/api) needs to be established manually as group routers won't create them by themselves
Aaron Stannard
@Aaronontheweb
Oct 16 2017 14:00
@uatec woah, how did that happen? can you draw a flowchart of that?
@JessieWadman we've made it clear in our release notes et al that .NET Core and .NET interop will not work with default serialization
won't work with Hyperion either
.NET Core moved all of the namespaces of those types around
and adding a compatibility shim for detecting that stuff would be hideously expensive
you're far better off ditching JSON.NET or Hyperion and just writing a Protobuf for your application if you need that type of x-plat stuff
eliminates the issue altogether without compromising performance
Robert Stiff
@uatec
Oct 16 2017 14:19
@Aaronontheweb it wasn't corrupted by akka.net, it was corrupted by me :|
fortunately the corruption was still in the journal and hadn't been persisted to the snapshot yet
also, how do you mean that default serialization wont work? I am default (newtonsoft) on .net core
Aaron Stannard
@Aaronontheweb
Oct 16 2017 14:20
default serialization between .NET framework and .NET Core doesn't work
for instance, a string lives in two different namespaces on each runtime
therefore an object serialized in .NET which has a string field can't automatically be deserialized on .NET Core
Robert Stiff
@uatec
Oct 16 2017 14:21
ah, between different versions of .net, i see
Aaron Stannard
@Aaronontheweb
Oct 16 2017 14:22
since the serializer sees the full qualified type name in .NET in the object's data and then can't find it when it tries to resolve the .NET Core
version of that same type
Jessie Wadman
@JessieWadman
Oct 16 2017 14:22
It works for the types handled by Hyperion, like byte, string, DateTime and arrays, so I could work around it!
Robert Stiff
@uatec
Oct 16 2017 14:24
rly? string looks like it's in System on both frameworks to me
Bartosz Sypytkowski
@Horusiath
Oct 16 2017 14:24
@uatec it's assembly name that matters here
Robert Stiff
@uatec
Oct 16 2017 14:24
ah
Bartosz Sypytkowski
@Horusiath
Oct 16 2017 14:25
@JessieWadman if I remember correctly, types from mscorlib in Hyperion have their assembly name replaced with some magic string - at least that was the case once
Jessie Wadman
@JessieWadman
Oct 16 2017 14:30
I saw the code for that, but it doesn't seem to be working for all types. But Hyperion has ValueSerializers for primitives, which I'm piggybacking on, like so...
    public class SomeType
    {
    }

    public class XPlatMsg
    {
        private SomeType[] items;

        public XPlatMsg(IEnumerable<SomeType> items, DateTimeOffset someDate)
        {
            this.items = items.ToArray();
            this.SomeDate = new DateTime(someDate.ToUniversalTime().Ticks, DateTimeKind.Utc);
        }

        public DateTime SomeDate { get; private set; }
        public IReadOnlyCollection<SomeType> Items => items;
    }
Can also make a public DateTimeOffset SomeDate => new DateTimeOffset(someDate, ...) to convert back and forth