These are chat archives for akkadotnet/akka.net

15th
Sep 2016
Marc Piechura
@marcpiechura
Sep 15 2016 05:06
@Aaronontheweb great! Replacement for the Interrupt call is already in the netcore branch see alexvaluyskiy/akka.net@3c6861a if you want to pick it
Peter Hvidgaard
@hvidgaard
Sep 15 2016 06:32
Is there any way to create an Actor from a background thread, which can use the "akka.actor.synchronized-dispatcher" dispatcher without capturing the context from a UI thread and injecting it?
it just seems to backwards.
Marin
@mrn-aglic
Sep 15 2016 11:06

I am not sure if this is a bug or not, or if this should be posted here or not, but here it goes...

I am using Akka.NET remoting, I have one "client" and one "server" application (I know akka doesn't distinguish between them) and I wanted to receive some entity (called History) from the server.

The class I was sending from the server has an IReadOnlyCollection of one of my custom entities (conveniently called Entity).
Now the Entity class had 2 constructors, first of which took a string and parsed it into a DateTime object, and the second which took a DateTime object.

However, when I tried to send this History from the server to the client I would get a disassociated exception.
Looking into it, I first commented out the construct that takes the DateTime object. However, when the other constructor was invoked, the string paramater (which I would like to parse to a DateTime) was equal to null.

Commenting out the constructor that takes a string and tries to parse it into a DateTime, I was left with only the second constructor which takes a DateTime object. This worked.

But I don't know why exactly it didn't work when I had both constructors, or why the string parameter was equal to null.

I can send or link the file with all of the classes if it could help.

Sorry if I am/was unclear.

Bartosz Sypytkowski
@Horusiath
Sep 15 2016 11:16
@mrn-aglic looks like a problem with serialization/deserialization - assuming you're using default (JSON.NET), it's probably not able to match the serialized fields with constructor arguments.
eyantiful
@eyantiful
Sep 15 2016 12:17
Hi guys, A question regarding cluster router, How can i prevent the router from receiving messages before its routees table is ready?
I mean is there some IsReady event i can get from the router?
asking the router for GetRoutees returns empty while not ready ....
Bart de Boer
@boekabart
Sep 15 2016 12:19
@mrn-aglic I always add unit tests for all types that need over-the-wire serialization, that tests their ability to be (de)serialized (and correctly so)
Using this helper:
public static class SerializerTestHelpers
    {
        public static async Task<T> AkkaSerialized<T>(this T src)
        {
            var hokon = "akka.actor.provider = \"Akka.Remote.RemoteActorRefProvider, Akka.Remote\"" +
                        Environment.NewLine +
                        "akka.remote.helios.tcp.port = 0" + Environment.NewLine +
                        "akka.remote.helios.tcp.hostname = localhost";
            var sys = ActorSystem.Create("src");//, ConfigurationFactory.ParseString(hokon));
            await sys.Terminate();
            var ser = sys.Serialization.FindSerializerFor(src);
            var bin = ser.ToBinary(src);
            return (T)ser.FromBinary(bin, typeof(T));
        }
    }
Bart de Boer
@boekabart
Sep 15 2016 12:25
If you use a different-than-default serializer, you configure it in the hokon string as you do for your application.
So you instantiate your class, then call .AkkaSerialized() on it, and compare the resulting output (if not an exception ;) ) with the input version. Should be equal enough for your use case.
Damian Reeves
@DamianReeves
Sep 15 2016 12:26
@boekabart thats a nice and straightforward utility method
Bart de Boer
@boekabart
Sep 15 2016 12:28
Just notice now that the hokon is not used in the code ;)
commented out
Damian Reeves
@DamianReeves
Sep 15 2016 12:29
Hey guys I've been looking at Akka.Interfaced, but before I dive headlong into making interface contracts for all my actors I wanted to know how everyone else manages the needs to have contracts/protocols for their actors so that they are approachable by all members of the team. I'm assuming Akka.Interfaced is not that widely used (but it does give you nice Orleans style interfaces to code against)
Ismael Hamed
@ismaelhamed
Sep 15 2016 12:44
When deleting events from the EventJournal in Akka.Persistence.SqlCommon, has the IsDeleted column any use anymore?
Ronnie Overby
@ronnieoverby
Sep 15 2016 12:55
@Aaronontheweb akkadotnet/akka.net#2308
Bartosz Sypytkowski
@Horusiath
Sep 15 2016 13:05

@DamianReeves in Akka (and other message based models) it's easier to define a contract on message level, i.e:

interface IMyProtocolMessage {}
sealed class MyMessage1 : IMyProtocolMessage {}
sealed class MyMessage2 : IMyProtocolMessage {}

Unlike method calls, messages are composable. You can wrap one message with another, batch them, redirect or persist if necessary. Also, you can define dynamic interfaces (through Become) with that.

For type safety it's possible to wrap IActorRefs with typed version (think IActorRef<IMyProtocolMessage>) - I've made this a default in Akkling.

Damian Reeves
@DamianReeves
Sep 15 2016 13:10
Hmm... that makes sense. So @Horusiath when you store IActorRefs in your actor implementations you store IActorRef<T>s so that that lets you know what set of messages you can send?
Bartosz Sypytkowski
@Horusiath
Sep 15 2016 13:12
yes, I use custom surrogate wrapper over existing one
which contains type parameter
Damian Reeves
@DamianReeves
Sep 15 2016 13:14
Cool, will crack open Akkling and take a look. I was starting to feel like the whole Akka.Interfaced approach was solving one problem but eliminating some of the benefits of a message oriented app model
Bartosz Sypytkowski
@Horusiath
Sep 15 2016 13:15
Akkling is in F# - in C# you can do a little more (F# doesn't allow you do explicitly define covariant/contravariant types)
Damian Reeves
@DamianReeves
Sep 15 2016 13:17
So what is the role of the TypedActorRefSurrogate<'Message>, is that for serialization purposes?
Bartosz Sypytkowski
@Horusiath
Sep 15 2016 13:18
yes, actor refs need to have their own custom serialization/deserialization strategy - they are not serializable/deserializable without context. This is where surrogates come to play.
Damian Reeves
@DamianReeves
Sep 15 2016 13:20
Ok, will have to look at examples of Akka's serialization surrogate usage. I like the pattern
Vagif Abilov
@object
Sep 15 2016 14:40
When using F# API and piping an async task, where should a client catch possible task cancellation exception?
I.e. if the code looks like
doSomethingAsync |!> mailbox.Self
And doSomethingAsync is cancelled
How does this cancellation propagated to an F# actor function?
Bartosz Sypytkowski
@Horusiath
Sep 15 2016 17:11
@object not tested but I guess it should be Failure message with TimeoutException inside
Ronnie Overby
@ronnieoverby
Sep 15 2016 17:46
Messages are not copied when being passed between local actors, correct?
Vagif Abilov
@object
Sep 15 2016 17:51
@Horusiath Failure message? What kind of message is it? Where is it defined?
Marc Piechura
@marcpiechura
Sep 15 2016 18:19
@ronnieoverby correct, that's also the reason why your messages need to be immutable
Ronnie Overby
@ronnieoverby
Sep 15 2016 18:19
Which is why I'm asking :)
Marc Piechura
@marcpiechura
Sep 15 2016 18:20
;)
Ronnie Overby
@ronnieoverby
Sep 15 2016 18:20
I'm adapting some legacy code to akka and was thinking about reusing some existing poco types that aren't immutable.
But doesn't look like that's a good idea.
Marc Piechura
@marcpiechura
Sep 15 2016 18:21
Yeah would probably lead to some race conditions especially if you have lists and so on in your messages
You could maybe use a base actor that does deep coping like orleans does but that would slow down all the things
Ronnie Overby
@ronnieoverby
Sep 15 2016 18:23
I don't have a big problem with writing mapping code to an immutable type
Marc Piechura
@marcpiechura
Sep 15 2016 18:39
@object If the F# operator is using the normal PipeTo extension method then it's Status.Failure, see https://github.com/akkadotnet/akka.net/blob/dev/src/core/Akka/Actor/PipeToSupport.cs#L32
Vagif Abilov
@object
Sep 15 2016 19:47
@Silv3rcircl3 yes it's using the normal PipeTo. Thanks for the link. Now it's clear.
Damian Reeves
@DamianReeves
Sep 15 2016 21:58
Since messages are supposed to be immutable why is it that we don't see more examples of using structs as message types. @Horusiath I looked at your AkkaCqrs example again and you are using structs, was that just an experiment, or is that how you commonly proceed?