Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 13:05
    IgorFedchenko commented #4085
  • 03:08
    hhko commented #4094
  • 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
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
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
but then you have to learn how all of that magic works and figure out precisely where and how you need to undo it when you inevitably run into a scaling issue
Akka does not. We give you the most bare bones defaults with the fewest moving parts and the best out of the box performance
it's up to you as the application architect to decide where trading off some of that performance in exchange for something like durability, message delivery guarantees, etc is more valuable
Ismael Hamed
@ismaelhamed
@Aaronontheweb I could share with you the logs, but I don't see any serialization exception
jalchr
@jalchr
@Aaronontheweb I see what you mean. But Akka.net is meant to be used for building "Reliable Distributed" processing systems. This means I have to do all the plumping in order to get a reliable system.
And we lack the presence of "Good" cluster oriented samples about getting guaranteed delivery.