akkadotnet/akka.net

Port of Akka actors for .NET

Ronny Carlansson

@lessismore1

Unable to find documention of HOCON. Need info about - akka.actor.ask-timeout. Pointers?

Bartosz Sypytkowski

@Horusiath

@lessismore1 akka.actor.ask-timeout was not originally part of JVM config, since in Scala you always have timeout as implicit parameter. We added it to allow people to set a global timeout on their Ask requests, so they don't need to pass timeouts each time. By default it's null (for backward compatibility story), but you can set it to any HOCON time value (i.e. 5s, 500ms etc.)

Ronny Carlansson

@lessismore1

Thanks for a quick reply! :) Working...

Bartosz Sypytkowski

@Horusiath

@gamemachine it's more the Orleans side - when you're calling grain methods, it's not just a simple await.

Ronny Carlansson

@lessismore1

Tried ImmutableSortedDictionary as actor state in a persistenceactor. Snapshots fails to load due to an requirement NewtonSoft have on immutables. Any hints?

Bartosz Sypytkowski

@Horusiath

@lessismore1 you may define your custom converter for json.net, or even better, you may define a custom serializer with well defined schema (i.e. protobuf, msgpack, ms bond)

Ronny Carlansson

@lessismore1

@Horusiath tried hyperion - same result. Something wrong the settings?

```
    serializers {
        hyperion = ""Akka.Serialization.HyperionSerializer, Akka.Serialization.Hyperion""
        bytes = ""Akka.Serialization.ByteArraySerializer""
    }
    serialization-bindings {
      ""System.Object"" = hyperion
      ""System.Byte[]"" = bytes
    }
```

Bartosz Sypytkowski

@Horusiath

@lessismore1 don't use Hyperion serializer for persistence - it's an anti-pattern

can you say what type are you actually trying to serialize?

Robert Stiff

@uatec

why is it an antipattern for persistence?

Bartosz Sypytkowski

@Horusiath

@uatec Hyperion should not be used for persistence for several reasons:

Most important it's still in beta and its binary format is unstable - it can be changed in the future. This means, that if you upgrade Hyperion library to newer version, you may be not able to deserialize your data any longer.
It uses a schema, but it's not defined explicitly like ie. in case of protobuf or msgpack. This means that if you shuffle order of the fields in your class, you may not be able to deserialize them any longer, or even worse i.e. deserialize value of field X as value of field Y- no error will be throw but the state of your data will be corrupted.
It's created for remoting - once we start using more advanced features of hyperion like sessions, some of the payload bytes will be context-dependent i.e. we won't be sending the same object twice over the wire, instead we can send only an identifier to an object we've send previously. It's great for connection-scoped messaging, but it will break in case of persistence.

ziya

@mtmk

Hey guys. Just created a simple cluster example using docker etc: https://github.com/mtmk/akkadotnetexamples/tree/master/containerized I'd really appreciate if anyone gives it a quick whirl and feedback.. thank you :smile:

Ronny Carlansson

@lessismore1

@Horusiath will not use it - was for testing purposes only :) Good info on hyperion!
Tried ImmutableSortedDictionary as part of actor state. Default serializer and hyperion gave same error :( Test over now, but thanks ... :)
The reason was that I noticed use of it in Akka.DistributedData

Ronny Carlansson

@lessismore1

@Horusiath old post from Aaron led me to believe that hyperion was the right choice for immutables AND persistence:
Akka.NET Near-Term Roadmap
no. 3 was new to me!

Robert Stiff

@uatec

i'm running this every minute:

this.DeleteSnapshots(new SnapshotSelectionCriteria(SnapshotSequenceNr - 10));
            this.DeleteMessages(base.LastSequenceNr - 100);

but i appear to have lost my state after restarting an agent

to my understanding, that should have meant that i had the last 10 (maybe 9) states to restore from

i guess i should check my logs

what i see is that I am receiving messages which do not correspond to the state I am expecting to heave

have

yeah, my state has reset to 0, then i have received many journaled messages that only really make sense if my state more recent

jalchr

@jalchr

Hi all,
I'm still thinking about this "at-most-once delivery" strategy which is the default in Akka.net. I'm wondering how can this 'default' help us build 'reliable' systems.
I appreciate if someone can share where is this policy / strategy helpful ?!
I can't find any single system that can work on none-guaranteed delivery.
I believe that "at-least-once" should be the 'default' in Akka.net. And this default should NOT require persistence. The acknowledgement should be built in.
And by-the-way, I have never found a "Solid" exactly-once delivery sample that works in a cluster.
And yes, I'm aware of those https://petabridge.com/blog/akkadotnet-at-least-once-message-delivery/ posts, which are 2 years old.
Just my thoughts ... appreciate your replies.

Ismael Hamed

@ismaelhamed

After this disassociated exception, the node gets marked as unreachable by the cluster and won't come back (it's being a hour now). I thought this type of exceptions were transient, and that eventually the node should recover:

Akka.Remote.EndpointDisassociatedException: Disassociated
   at Akka.Remote.EndpointWriter.PublishAndThrow(Exception reason, LogLevel level, Boolean needToThrow)
   at Akka.Actor.ReceiveActor.ExecutePartialMessageHandler(Object message, PartialAction`1 partialAction)
   at Akka.Actor.UntypedActor.Receive(Object message)
   at Akka.Actor.ActorBase.AroundReceive(Receive receive, Object message)
   at Akka.Actor.ActorCell.ReceiveMessage(Object message)
   at Akka.Actor.ActorCell.AutoReceiveMessage(Envelope envelope)
   at Akka.Actor.ActorCell.Invoke(Envelope envelope)

Robert Stiff

@uatec

only up to a point

i think there are some limits

it's like a 3 strikes and your out, kinda thing

i just had a look through the code, it's pretty complicated how something gets marked as Quarantined

but one it is, then that node needs restarting

Robert Stiff

@uatec

something to do with the message buffer becoming out of sync

Ismael Hamed

@ismaelhamed

Yep, restarting the node fixes it. Which is why it seems obvious that retrying would fix it eventually (though, as you said, I get it's more complicated than that)

Michel van den Berg

@promontis

@Horusiath when using cluster sharding and remembering entities, should I be handling ShardRegion.StartEntity?

Ismael Hamed

@ismaelhamed

The thing is this behavior is gonna be troublesome in production, since now this requires manual intervention

Michel van den Berg

@promontis

If so, this is not really obvious from the Akka.NET docs or the samples

your sample really helped me

https://github.com/Horusiath/AkkaDemos/blob/master/cluster-sharding/Demo.ClusterShared/Sharding.cs#L33

maybe we can put there a comment that other types of objects should be handled there as well, if needed

Aaron Stannard

@Aaronontheweb

@ismaelhamed I'm worried this might be a serialization error

those errors are NOT transient right now

although in some cases they probably should be

I believe that "at-least-once" should be the 'default' in Akka.net.

Aaron Stannard

@Aaronontheweb

cc @jalchr the tradeoff there would be an order of magnitude decrease in the throughput of Akka.NET across the board and a 1-2 order of magnitude increase in the amount of memory consumption message sending uses

which is, simply put, a bad trade off

Ismael Hamed

@ismaelhamed

@Aaronontheweb by serialization, you mean persistence or remoting?

Aaron Stannard

@Aaronontheweb

at least once delivery is not hard

@ismaelhamed remoting

but it is expensive

and it's much easier on the software developer to "opt in" to it where they need it

than it is to "opt out" of it where you don't

Microsoft designs their tools the latter way - use all of the CPU and memory-expensive techniques to babyproof your application from day one

Where communities thrive

People

Repo info

Activity