Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 14 21:02
    Aaronontheweb synchronize #3975
  • Oct 14 21:02
    Aaronontheweb opened #3975
  • Oct 14 20:11
    IgorFedchenko commented #3973
  • Oct 14 20:10
    IgorFedchenko synchronize #3973
  • Oct 14 20:06
    IgorFedchenko synchronize #3973
  • Oct 14 20:06
    IgorFedchenko synchronize #3973
  • Oct 14 19:42
    IgorFedchenko edited #3973
  • Oct 14 18:08
    Aaronontheweb commented #3937
  • Oct 14 17:27
    Aaronontheweb commented #90
  • Oct 14 17:26
    Aaronontheweb commented #90
  • Oct 14 17:25
    Aaronontheweb assigned #90
  • Oct 14 17:16

    Aaronontheweb on dev

    Provide static GetRoutees.Insta… (compare)

  • Oct 14 17:16
    Aaronontheweb closed #3974
  • Oct 14 17:16
    Aaronontheweb milestoned #3974
  • Oct 14 16:05
    jackowild opened #90
  • Oct 14 15:08
    Aaronontheweb commented #3974
  • Oct 14 15:08
    Aaronontheweb commented #3974
  • Oct 13 14:40
    cptjazz synchronize #3974
  • Oct 13 14:07
    cptjazz opened #3974
  • Oct 13 08:30
    ismaelhamed commented #3937
Aaron Stannard
@Aaronontheweb
because that'd break encapsulation and all sorts of other bad things
nathvi
@nathvi
It may be just me, but I feel like having that further elaboration on how this is used with local messages and what that means would make the documentation more clear.
Good candidate for pr?
Aaron Stannard
@Aaronontheweb
yeah
that's a good idea
nathvi
@nathvi
:)
I'll do that.
@Aaronontheweb , do you work for Petabridge?
Aaron Stannard
@Aaronontheweb
yep
nathvi
@nathvi
cool
How's this for an edit?
"
Another good practice is to declare local messages (messages that are sent in process) within the Actor, which makes it easier to know what messages are generally being sent over the wire vs in process.
"
nathvi
@nathvi
Just made a pull request for it akkadotnet/akka.net#3380.
nathvi
@nathvi
I think it would be cool to make an interactive game showing how all the parts relate.
Maybe I'll do that as a side project.
nathvi
@nathvi
I'm confused about this in the documentation...
"Akka persistence also provides point-to-point communication with at-least-once message delivery semantics." Why would persistence be mixed in with networking?
Ismael Hamed
@ismaelhamed
For a QoS of type At-Least-Once you'd probably want to use some sort of durable storage
nathvi
@nathvi
Is it possible to have windows service A on machine 1 build an actor A1 in windows service B on machine 2, and if service B is restarted, actor A1 will be persisted?
Jesse Connor
@jesseconnr

I have an aggregator that accepts messages from a remote actor service. I built it because sending all of the data at once was just too large of a message. However, now that it's getting a few thousand messages I'm seeing errors like this.
Akka.Remote.Transport.AkkaProtocolException: Error while decoding incoming Akka PDU of length 28564 ---> Akka.Remote.Transport.PduCodecException: Decoding PDU failed

DotNetty.Codecs.TooLongFrameException: Adjusted frame length exceeds 128000: 128061958 - discarded

I'm on Akka 1.3.2, haven't tried upgrading yet, but even so I didn't see anything that stood out in the release notes that would indicate it's a bug. Anyone ever see anything like this when sending large amounts of messages? At the lower end, if I'm just sending a few hundred I don't get this error.
Jesse Connor
@jesseconnr
Seems to happen after a few hundred messages, but randomly. If I reverse the order or sort the list of messages sent over the wire in various way it doesn't have an affect on where the error occurs.
Marc Piechura
@marcpiechura
@jesseconnr looks like the same as this issue akkadotnet/akka.net#3327
Jesse Connor
@jesseconnr
Perhaps, but I believe before I upgraded I was on DotNetty 0.4.6. Also, upgrading didn't fix it and the first message it fails on is only 28kb, same size every time. The error that follows claims there's a 128MB frame, but I have no idea how or where that would come from. The entire database that holds the messages I'm sending isn't even that large.
nathvi
@nathvi
I'm wondering why Akka.Net decided to be dependent on DotNetty? It seems really immature and untested.
nathvi
@nathvi
Does Akka.Net provide Exactly-Once Semantics?
nathvi
@nathvi
Nvm, I just saw @Aaronontheweb 's video on making message buffers to deal with that problem.
nathvi
@nathvi
So I have the following pattern. Please let me know if it makes sense. I have a TeacherActor and a TeachersAssistentActor. The TeacherActor creates the TeachersAssistentActor as a child. Whenever the TeacherActor receives a message of type "BoringWorkMessage", it forwards it onto the TeachersAssistent. When the TeachersAssistent gets the BoringWorkMessage, there is a certain probability that the work is too boring, and the TeachersAssistent commits suicide by throwing an exception. The teacher can restart the TeachersAssistent via a SupervisorStragegy
Jesse Connor
@jesseconnr
@nathvi sounds correct to me, I do the same setup, just with different naming, OrderRouter starts all OrderActors and when they die for whatever reason it starts them back up. You may want to read up on the PreStart, PreRestart and PostRestart events that affect that behavior as well.
Ex. by default if the TeacherActor decides the work is so boring that it decides to commit suicide even before forwarding the message to an assistant, the PreRestart event will restart all children.
nathvi
@nathvi
@jesseconnr , generally you want to push dangerous work to children, correct?
Jessie Wadman
@JessieWadman

I'm curious to know what indexing patterns people are using for persistent, remembered, sharded entities, when you need to lookup/address them by something other than the entity ID. Since shards can migrate between nodes, there's always a chance that a shard is currently "offline", so broadcasting/aggregating cant' always be consistent (i.e. while a shard is starting up on a node and loading all entities, those entities won't respond to the broadcast). Consider you have an entity called Contact, with it's ContactID, and you want to find all contacts with a specific phone number. You could of course map the index in a SQL table or something, and do the lookup there. But I'd like to avoid a database roundtrip if possible. Currently I'm using a secondary sharded entity whose entity ID is the "indexed" field, that does nothing other than rewrap the message with the now-known actual EntityID and forward it to its counterpart. It works well, but if you index 4-5 fields, for 100K entities, then you suddenly have 500K-600K entities that a cluster needs to fetch from the event journal on startup (instead of just the 100K), which slows down the startup significantly (lots of DB roundtrips). I've experimented with a cluster singleton that keeps track of indexes, and whenever entities are recovered/altered, they notify the singleton. It works great when the cluster is up and running, and it's fast, but when booting up, lookups return false negatives because the shard hasn't loaded yet and the entities haven't registered. So, I'm curious to know what solutions other people have found for this type of scenario. Are all the cool kids using doing this outside of Akka with SQL tables or similar?

I also considered using singleton with the broadcast/aggregate pattern against the entities, and hook into the cluster node and sharding lifecycle messages to keep track of when "partitions" are online or offline, and buffer broadcasting whenever one of the shards is offline, but that hits pretty hard against "availability" metric.

Onur Gumus
@OnurGumus
image.png
Hey guys, I am playing with intellitrace support of akka messages
How do you like it?
Aaron Stannard
@Aaronontheweb
@nathvi DotNetty powers the Azure IoT hub
and it's a port of Netty, which is itself very highly battle tested
DotNetty could afford to be more robust in the QA department though
Bartosz Sypytkowski
@Horusiath
@JessieWadman at this moment there's no build in support for sharded entities querying mechanics. It's possible to build one either using event journals with live queries, or distributed data.
ShalokShalom
@ShalokShalom
Akka uses pure cooperative objects on OS threads, thus it can be locked down. In addition a fault in any of the actors can bring down the entire CLR pretty easily. Correct?
Bartosz Sypytkowski
@Horusiath
@ShalokShalom not any kind of faults - as standard exceptions inside actors are catched and supervised - but the critical faults of .NET environment can (i.e. out of memory exception), simply because some failures in .NET cannot be revoked.
ShalokShalom
@ShalokShalom
Yes
Thanks a lot :D
ShalokShalom
@ShalokShalom
Can a rewrite of the CLR itself in Akka help?
Bartosz Sypytkowski
@Horusiath
no, akka is only a library on top of CLR not a platform on itself. Some platforms like Erlang or Pony have isolated memory model that provide a higher degree of safety in terms of VM-wide failures.
AltcoinsBattle
@AltcoinsBattle_twitter
Journal
    .EventsByPersistenceId(inventoryName, ++inventoryOffset, long.MaxValue)
    .RunForeach(HandleCharactersEvent, Materializer);

Journal
    .EventsByPersistenceId(descriptorItemsName, ++descriptorOffset, long.MaxValue)
    .RunForeach(HandleCharacterDescriptionEvent, Materializer);
Does Akka guarantee that this code will process one message at a time?
It is probably the VS debugger, but it shows the two Handle methods invoked in parallel
I see some bug in my code (from client side) and cannot catch it, looks like can be related to multithreading, that is why I'm asking :)
Marc Piechura
@marcpiechura
RunForeach isn’t blocking, it returns a Task I think which you can await before running the second loop
Since persistence query is based on Akka.Streams you’re ending up with two actors under the hood which run the two queries in parallel