Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 13 21:37
    Aaronontheweb commented #4085
  • Dec 13 20:28
    IgorFedchenko commented #4085
  • Dec 13 20:27
    IgorFedchenko commented #4085
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb milestoned #4096
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb opened #4096
  • Dec 13 10:41
    peirens-bart opened #4095
  • Dec 13 08:37
    Aaronontheweb synchronize #4071
  • Dec 13 08:13
    jiyeongj opened #4094
  • Dec 12 15:42
    Aaronontheweb synchronize #4086
  • Dec 12 15:42
    Aaronontheweb closed #4083
  • Dec 12 15:42

    Aaronontheweb on dev

    Fix #4083 - Endpoint receive bu… (compare)

  • Dec 12 15:42
    Aaronontheweb closed #4089
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb opened #4093
  • Dec 12 14:20
    Aaronontheweb commented #4092
  • Dec 12 14:14
    Aaronontheweb labeled #4089
Chris Ochs
@gamemachine
So long time user of akka but decided to give orleans a shot on my current game. I've noticed something very different at a core level, which is orleans is slow as hell. SOme of it is the serialization, but some of it appears to be that await is just slow. Does akka internally use some magic to make sending messages faster then a simple await?
on akka jvm as of around 2 years ago, the same basic logic I was pushing 50k messages second. Akka.net I didn't do as much testing, but it wasn't far behind at around the same cpu load. Orleans falls over at the same load, doesn't even get 20% of the way there
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:
  1. 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.
  2. 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.
  3. 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
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