These are chat archives for akkadotnet/akka.net

10th
Dec 2016
Aaron Stannard
@Aaronontheweb
Dec 10 2016 02:53
@corneliutusnea ball is moving forward on that
going to give Helios the boot here shortly so we can finish our end-to-end .NET Core impl
part of 1.5
@gamemachine please report a bug on that second part with some more details
pretty sure I know what that issue is
spent 1.5 hours today pouring over the guts of ClusterClient and some of the DistributedPubSub stuff
trying to hunt down a bug there
would be handy to have that additional info while we wait
as for your first question
put the code for your cleanup / graceful termination into PostStop
that has to execute before the parent gets killed
each child gets to run its PostStop method before its terminated
so that's the appropriate area for it
if you need to get some messages back as part of your cleanup process, use Ask and .Wait to block
either that or split the actor off into its own part of the hiearchy and have it deathwatch the parent
and have it begin its termination process once the parent dies
Claudio Bernasconi
@claudiobernasconi
Dec 10 2016 15:39
Hi folks. Seems like I have a major problem understandig some fundamentals of Akka.net. I currently have the following Actor System:
BatchJobSystem.png

I use a Round-Robin-Pool-Router for my Worker Actors. The JobCoordinatorActor keeps track of how many "rows" have been processed by the workers. This works really well.

My problem is that I currently have to create the JobCoordiantorActors all on my own. This means that if I create 100 Jobs, 100 JobCoordinatorActors will be created and run simultaneously. What I really want is that I can start 100 jobs, but only 10 JobCoordinatorActors will run at the same time.

Therefore I tried to implement the JobCoordinatorActor as a Round-Robin-Pool-Router as well. The problem is, that I don't know how I can "block" the JobCoordinatorActor so that it keeps wainting until its workers finished, then finish the JobCoordinatorActor and take the next job from the queue.

Can you guide me to the right article / resource to solve my misunderstandig? Thank you very much.

Claudio Bernasconi
@claudiobernasconi
Dec 10 2016 15:47
Ah maybe I got it. Do I have to use Actor behaviors so that I can tell a coordinator to be in "running" state which only accepts messages from its workers and after completing switch to "ready4work" state which allows to receive the next StartJobMessage?
Claudio Bernasconi
@claudiobernasconi
Dec 10 2016 16:33
I now refactored my solution to make use of switchable behaviours within my Coordinator. My problem no is that I only get as many messages as instances of the Coordinator. My coordinator completes, changes its baviour to accept the next "StartJobMessage", but there won't be a new one. I am sure that I initally sent workload with 5 times the number of coordinators. How can it be that these messages disappear? Any help highly appreciated.
Bartosz Sypytkowski
@Horusiath
Dec 10 2016 16:42
@claudiobernasconi When your actor is in running behavior, how do you handle StartJobMessage?
Claudio Bernasconi
@claudiobernasconi
Dec 10 2016 17:36
@Horusiath when my actor is in running behavior I do not handle StartJobMessage. My code looks like this:

private void Running() {
Receive<WorkerCompletedMessage>( msg => HandleWorkerCompletedMessage(msg));
}

private void Ready(){
Receive<StartJobMessage>(msg => HandleStartJobMesage(msg));
}

so its either one message or the other. Is this the wrong approach?
I've somewhere read that it is possible to consume a message and put it back onto the stack or something like that. But i am not used to this concept. The way I think about it by now is that if I do not handle a specific message type in a specific behaviour that the message stays in the queue. Is this assumption wrong?
Bartosz Sypytkowski
@Horusiath
Dec 10 2016 17:50
if message would stay in queue it would block all further messages. By default all unhandled messages are thrown to dead letters.
Claudio Bernasconi
@claudiobernasconi
Dec 10 2016 17:51
Okay this explains the observed bahaviour. Can you guide me how I should implement it? Seems like I need to consume the message and put it back to (another) queue again?
Bartosz Sypytkowski
@Horusiath
Dec 10 2016 17:52
there is a possiblity of using stashing, so that in case if you don't want to handle message yet, you can stash it aside, and at some point unstash all messages back to actor's mailbox
Claudio Bernasconi
@claudiobernasconi
Dec 10 2016 17:55
Okay. I have a round robin router which has 10 JobCoordinatorActors. I assume that the round robin router tries to deliver the StartJobMessages to all of the 10 JobCoordinatorActors. So do I have to stash them for each JobCoordinatorActor?
Bartosz Sypytkowski
@Horusiath
Dec 10 2016 17:56
it would be hard to do otherwise.
round robin router will evenly send message to all 10 actors. Each of them can stash a message when in receiving state, and then just unstash all of them when switching back to watingforjob state
Claudio Bernasconi
@claudiobernasconi
Dec 10 2016 17:59
Okay seems reasonable. I will try this tomorrow (it's 7pm. here), but conceptually this seems to solve my issue. Thank you very much.
Bartosz Sypytkowski
@Horusiath
Dec 10 2016 18:00
no problem ;)
Maxim
@dubrovkinmaxim
Dec 10 2016 23:24
Hi guys. I have question about delivery strategy "at-least-once-delivery". As I understand after redeliver-interval all messages (which were not marked as delivered) will be delivered again. What's best practises to configure this behavior? Which redeliver-interval should I use in my cluster when I don't know how many messages will appear in input of this actor?
Maxim
@dubrovkinmaxim
Dec 10 2016 23:35
For example: 10 000 messages are processed during 10-20 secs. I have redelivery-interval = 20 secs. What's will happen if in next iteration AtLeastOnceDeliveryReceiveActor receive 50 000 messages? As I undestend it will processed 10 000 messages(20 sec) after that 40 000 will redelivered again (40 000 + 40 000 =80 000 messages in mail box). Is it true? =)