Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 09 20:47
    IgorFedchenko commented #4085
  • Dec 09 20:46
    IgorFedchenko commented #4085
  • Dec 09 15:09
    IgorFedchenko commented #4085
  • Dec 09 11:24
    Kenji-Tanaka commented #3887
  • Dec 09 10:45
    nagytech edited #4086
  • Dec 09 10:45
    nagytech synchronize #4086
  • Dec 09 10:43
    nagytech opened #4086
  • Dec 09 09:00
    Horusiath commented #4077
  • Dec 09 06:31
    Aaronontheweb commented #4085
  • Dec 09 06:28
    Aaronontheweb commented #4085
  • Dec 09 06:24
    Aaronontheweb commented #4085
  • Dec 07 11:49
    IgorFedchenko commented #4085
  • Dec 07 10:31
    IgorFedchenko commented #4085
  • Dec 07 08:36
    IgorFedchenko commented #4085
  • Dec 06 20:57
    IgorFedchenko commented #4085
  • Dec 06 20:32
    IgorFedchenko commented #4085
  • Dec 06 20:01
    IgorFedchenko commented #4085
  • Dec 06 19:55
    IgorFedchenko commented #4085
  • Dec 06 16:22
    Aaronontheweb labeled #3997
  • Dec 06 16:22
    Aaronontheweb closed #3997
Arsene
@Tochemey
@goodisontoffee Thanks man. It works :smile:
Kevin McFarlane
@kevinmcfarlane
I notice that that the Akka.NET home page has some broken links in the "read more." Also the copyright is saying 2013-2016.
Aaron Stannard
@Aaronontheweb
@kevinmcfarlane would you mind logging an issue with some of those? we'll fix it
the copyright footer fix should be a breeze too
Kevin McFarlane
@kevinmcfarlane
Hi Aaron, I'll try and do so over the weekend. At work at the moment. :)
Michel van den Berg
@promontis
What to do when I have a coordinator actor that will deploy work to worker actors on a number of nodes and the number of worker actors is very high (say a million). The coordinator actor is persistent and has a million WorkerCreated events. Will this one coordinator actor be able to handle the creation of a million worker actors by reading the journal? Or will this take a long time? If so, how to speed this up?
Robert Stiff
@uatec
hey
https://getakka.net http cert appears to be wrong
getting an azure websites one
Gregorius Soedharmo
@Arkatufus
uh oh...
i'll let the other core team member know, thanks
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