These are chat archives for akkadotnet/akka.net

30th
Apr 2016
Aaron Stannard
@Aaronontheweb
Apr 30 2016 00:59
@Horusiath @corneliutusnea Helios stuff most likely - which as I mention just about every day: I'm working on right now. Currently at 50 hours logged for the week on this stuff. Been about the same for the past 3.
1.0.8 definitely fixed some rejoin issues
but the underlying transport needs love
I'm trying to get something out this coming week, but given the previous quality control issues with Helios I'm benchmarking and covering each component with model based tests as I go
Aaron Stannard
@Aaronontheweb
Apr 30 2016 01:04
which is laborious but totally worth it so far
I'll keep you guys posted
Alex Valuyskiy
@alexvaluyskiy
Apr 30 2016 05:46
@Aaronontheweb it is strange, that we have many problems with underlying transport, but all akka multinode tests passed
Aleksandrs
@sonicflare
Apr 30 2016 09:42
Hello guys :)
How do you manage/design actor interactions without deadlocks. I have a actor system, where each actor is a service that can process multiple types of messages, and it can call other services as well. This works perfectly fine, but when i load test it, what happens, the first actors will get busy on processing the messages (all instances of this actor will pickup and start processing message) and it will call other services, but what happens, is as part of the pipeline, of the the actors below is calling the upper actor to get some additional info, but as those are all waiting for response from other actors, the whole process under load deadlocks. I mean, yes, this probably a design problem, but are there any tips, guides on how to deal with it?
On a large system with many developers, those interactions could become unmanageable. Do you split the actor into multiple ones that will only process one message type and put those behind router?
Bartosz Sypytkowski
@Horusiath
Apr 30 2016 09:49
This message was deleted
@sonicflare Your problem is oriented around request/response model, not actors. If you're using request/response pattern, you can easily fall into deadlock situation, as it's inherently blocking communication pattern.
I don't have much time, so I won't be able to give you a full response. I'm going to publish post on the problem with RPC in actor model soon to fully describe it.
For your issue you'd need to describe your case in greater details.
Aleksandrs
@sonicflare
Apr 30 2016 10:34
Yes, this is the Request/Response pattern using Ask. everything is async, so the thread pool is not a problem.
The setup looks like. (from left to right) Left is where the high level messages are coming, like create something, and the most left actor is responsible for coordinating all the calls to create some entity. I use group routers, with RR balancer. Each of the actor is responsible for processing a single entity type (ie microservice). And creation of some entity needs to create some other child entities, and in some cases some additional information about the entity from the root. (call from the right to left). As the group router assigns messages to all available instances, all the new messages will be queued. And as the response from the root is required to complete the outer request, the whole thing deadlocks. The root actor waiting for the response from the actors that creates another entitiy, and this entity creation actor waiting for the answer from the root actor.
So, im thinking of the following options: Extract the functionality/refactor the messages to eliminate the need to make this call.
Make a dedicated instances for the root actor that will only handle those types of messages (via Receive predicate)
Make a more smarter router actor that will take into account the messages type for the actor and spawn more instances of demand or analyze all the message flow and make some kind of chart on how many instances are needed of what actor types to eliminate deadlock situations
Bartosz Sypytkowski
@Horusiath
Apr 30 2016 12:03
@sonicflare when I'm talking about blocking, I don't mean threads. When using request/response, you're effectively blocking your actor (as it cannot receive any new messages until it gets responded). Also:
  • Why are you using Ask between actors?
  • What information does most left actor have, that is necessary in the lower hierarchy, and why does it need to wait for other actor to finish it's job? This looks like a violation of Single Responsibility Principle.
kariem-ali
@kariem-ali
Apr 30 2016 13:05

Hi, can someone answer this for me please?

Hi Guys. If I use PersistAllAsync and PersistAsync in two different message handlers in the same actor. Are the persisted objects guaranteed to be persisted in the order the messages came in?

Aaron Stannard
@Aaronontheweb
Apr 30 2016 13:53
@alexvaluyskiy it's not that bad, the transport - people have been using it successfully in production for years. But it does have some known issues that are easy to reproduce. the MNTR does racily fail regularly