These are chat archives for petabridge/akka-bootcamp

17th
Jun 2015
Igor Ziselman
@constructor-igor
Jun 17 2015 03:57
Now I understand: my test doesn't wait finish of execution: thus, async actors aborted by main thread. By the way, how can I wait in test when all actors will complete execution? actorSystem.AwaitTermination(); cannot help here. How can be implemented "termination when all actors will complete execution"? Found a answer in stackoverflow http://stackoverflow.com/questions/30086118/how-do-i-wait-for-all-work-to-complete-in-akka-net
Andrey
@AndrewEgorov
Jun 17 2015 05:35
Hello All. I have a few questions about remote deploy. How correctly kill remotely deployed actor so it wasn't present any more in the system. For a sample we can use RemoteDeploy example on git. After deploytarget received a msg we send msg to deployer to kill self and deployer ref from deploytarget childrens (difficult explain without code). How correctly to do that? Thanks in advance.
Context.Stop() and Context.Unwatch() works not as i expected in Deployer (it kill actor in DeployTarget system, but not removes it from current context)
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 05:39
yeah, definitely it's better to discuss that on the example ;)
but in general Context.Stop doesn't kill immediately (it sends a termination order on the actor's mailbox)
also I don't know what are you talking about in "not removes it from current context"
Andrey
@AndrewEgorov
Jun 17 2015 05:44
also I don't know what are you talking about in "not removes it from current context" - i mean next. Let's assume that i have two actors (Server, Actor). In Server in message i create a remote child on remote machine (Actor). So server now have children Actor deployed remotely. After Actor finished job it sends message e.g. JobDone back to Server and Server kills Actor by calling Context.Stop(actor). After that few moments ago server receives new task and creates remote actor again and here i can observe that prevoious actor (which i thought would deleted) still present in Context.Childrens list.
name of Actors are hardcoded (e.g. Actor1, Actor2) etc. So after killing it i want to restore actor with same name on remote system. And as you can guess i got exception because it still presents in the system after i thought it was killed
i can solve problem and not hardcode names, but i want to know correct way of killing remote actors and remove it from Server's context. Thanks =) hope it's clear now
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 05:57
could you provide some example?
Andrey
@AndrewEgorov
Jun 17 2015 05:57
where? (git or here? =) )
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 05:58
https://gist.github.com/ is good for bigger snippets
Andrey
@AndrewEgorov
Jun 17 2015 05:59
ok
Andrey
@AndrewEgorov
Jun 17 2015 06:31
i've published sample of the code here https://gist.github.com/AndrewEgorov/53bbbcbd891bea6b4c3e you can use sample of akka remote deploy (https://github.com/petabridge/akkadotnet-code-samples/tree/master/RemoteDeploy) and replace content of files posted in gist
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 06:54
@Aaronontheweb @rogeralsing any ideas?
Roger Johansson
@rogeralsing
Jun 17 2015 07:11
TLDR; is the problem that killed remote deployed actors arent removed from the child container?
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 07:11
yes
Roger Johansson
@rogeralsing
Jun 17 2015 07:12
ok, remote deployed actors are stored in a "virtual container" which is different from the normal child container.. it might very well be an issue in that
Andrey
@AndrewEgorov
Jun 17 2015 07:22
@rogeralsing , so, how to remove it from this "virtual container"? Or what i can do to solve that issue? Thanks
Jens Pettersson
@jenspettersson
Jun 17 2015 07:39
Hello! When using Remote Deploy, if the "Deploy Target" is shut down/restarted the "Deployer" gets an exception but when the "Deploy Target" comes back up again, is there a way to get the Deployer to reconnect again, without the need to restart the deployer as well?
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 07:44
when "Deploy Target" actor system comes back up again, you can work with it as regular
Jens Pettersson
@jenspettersson
Jun 17 2015 07:47
But the existing "Deployer" doesn't seem to reconnect without having to restart it. In the RemoteDeploySample, if you start both the Deployer and the DeployTarget it starts sending messages, but if you restart the DeployTarget (and keep the Deployer running) when the DeployTarget is started again, no messages are processed from the Deployer.
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 07:49
when remote system dies, all actors that where remotely deployed on it, die as well - so when system will raise up again, you need to recreate actors first before sending a messages
Jens Pettersson
@jenspettersson
Jun 17 2015 07:50
Ok. Is there a way to hook into this so the Deployer knows when the DeployTarget dies (and later comes back up) so it can start recreating the actors and deploy them again?
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 07:53
you can use Context.Watch(IActorRef) to link two actors together - when watched actor dies, watcher will get Terminated message with details about actor's death
Jens Pettersson
@jenspettersson
Jun 17 2015 07:54
Ah, thank you! Was looking for stuff on the ActorSystem itself, but I should look in the actual actor(s) instead. Thanks, makes sense!
Jens Pettersson
@jenspettersson
Jun 17 2015 08:59
Now I have another problem... I'm hosting one ActorSystem in a WebAPI on IIS and the Remotes gets the Terminated message when I STOP the ApplicationPool, but when I only recycle it, I get an Akka.Remote.ResendUnfulfillableException: Unable to fulfill resend request since negatively acknowledged payload is no longer in buffer. The resend states between two systems are compromised and cannot be recovered. Any ideas why?
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 09:02
@Aaronontheweb should know more, but for me it looks like there are still messages pending to being send when connection stops
Jens Pettersson
@jenspettersson
Jun 17 2015 09:03
Might be the Terminted message that's pending... Maybe it's not recommended to host an ActorSystem in an IIS and let other ActorSystem remotely deploy there?
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 09:04
you're deploying on the IIS actor system from other actor systems
?
Jens Pettersson
@jenspettersson
Jun 17 2015 09:08
yes. We have an older "legacy" system hosted on IIS and we are looking for an easy way for other services to notify that system. Was easy to just create an ActorSystem in the Application_Start and then let other services remote deploy there. Works fine, until the IIS is recycled... Maybe RemoteDeploy is overkill, might just use ActorSelection to the IIS as these notifications are trivial and it doesn't matter at all if the IIS goes down while notifying
Or, I'm approaching this the wrong way. That's usually the issue ;)
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 09:13
I'm not sure, what are internal differences between IIS stop/recycle... do you get this exception on IIS deploy target system, or on the deployer system? (Deployer if I'm right)
Jens Pettersson
@jenspettersson
Jun 17 2015 09:14
On the Deployer system
When I stop the app pool, first I get the Disassociated exception and then a couple of seconds later I get the Terminated message. Might be that when recycling it's restarting the app before the Terminated message was sent.
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 09:19
maybe first question I should ask - does that exception concern you (actor cannot be created or message cannot be delivered)?
Jens Pettersson
@jenspettersson
Jun 17 2015 09:23
Not sure I understand the question... The ResendUnfulfillableException? when that occurs I never get the Terminated message so I can't really act on anything...
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 09:24
ok, I was thinking that you received Terminated messge ;)
Jens Pettersson
@jenspettersson
Jun 17 2015 09:25
nope, only when the app-pool is STOPPED but not when recycled... So when the app-pool is stopped I can act on the Terminated message and try to recreate my remote actor, but since the app-pool most likely will be recycled I have to be able to get some sort of termination message then as well
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 09:29
I'm thinking about using registration hooks for IIS, these are plugins which allows you to bind to events (such as restart I supose) generated by IIS - I know that dealing with background job on IIS is pain in the ass
Jens Pettersson
@jenspettersson
Jun 17 2015 09:31
Thanks. Will look at that. However, I just found that if I put a debug point in the Application_End while recycling the application pool, the remotes DO indeed get the Termination message.
Igor Ziselman
@constructor-igor
Jun 17 2015 10:23
According "Lesson 1.6: The Actor Lifecycle" PreStart() doesn't require to call base method, but PostStop() requires to call base method. correct?
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 10:24
yes, for most actors
Igor Ziselman
@constructor-igor
Jun 17 2015 10:25
Why is not symmetrical?
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 10:28
for me the rule of thumb is to always call base method implementation (just in case). In this specific case PreStart is method hooked in Actor's lifecycle. It's not used in basic actor's implementations (but i.e. it's used by PersistentActor in Akka.Persistence). PostStop also is a hooked to lifecycle event, but base implementation additionally does few more things i.e. it stops all of the actor's children.
Igor Ziselman
@constructor-igor
Jun 17 2015 10:30
may I call base method for PreStart (for symmetry)?
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 10:30
yes, of course
Andrey
@AndrewEgorov
Jun 17 2015 16:52
@Horusiath , sorry, but any updates on my question?
Aaron Stannard
@Aaronontheweb
Jun 17 2015 18:57
@AndrewEgorov if the Context.Stop isn't working, you can try sending a PoisonPill.Instance to that remote actor and see if that removes it
but this sounds like a bug
I'll log it and see if we can fix it
Bartosz Sypytkowski
@Horusiath
Jun 17 2015 19:02
@Aaronontheweb I tried @AndrewEgorov example with PoisonPill - same result. Looks like bug
Roger Johansson
@rogeralsing
Jun 17 2015 19:38
I found the problem
we dont have any code for handling deathwatchnotification in RemoteDaemon..