0

I’m creating a router using the router configuration in application.conf.

In a situation I need to manually remove the routes and add routes to my router. I saw in akka-scala document (link), using removeRoutee and andRoutee we will be able to achieve it.

But since I’m creating the router using configuration I can select the router using the following code.

var router = Akka.system().actorSelection("/user/intelliSupervisor/router")
    var routerFut = router.resolveOne()(10)

    routerFut.onComplete {
      case Success(actor) => {
        // 'actor' RoutedActorRef
      }
      case Failure(ex) =>
    } 

In the future onComplete Success call it's returning akka.routing.RoutedActorRef. How can I access the created akka.routing.Router ? or is there anyway I can covert it to a router object ?

Thank you very much in advance.

Renien
  • 551
  • 4
  • 19
  • A router is an Actor (albeit with a specialized mailbox) and should only be communicated with via it's `ActorRef` like regular Actors. You should not mutate it's internal state (routees in this case) from anywhere outside of the router instance. Why don't you describe your situation in a little more detail, like what drives adding/removing routees and maybe I can offer a better solution for you. – cmbaxter Feb 11 '15 at 15:54
  • 3 layers of actors, ROUTER [RT]->SUPERVISORS [SPS]->WORKERS [WKS]. The WORKER [WK] does a job with the python server. In a situation I need to restart python server. So I have implemented the Reaper pattern to keep track on each WKS. When the situation comes I will send POISONKILL to a particular WORKER [WK] and during the Termination I’ll send a message to SUPERVISOR [SP] to recreate again my worker. During this process RT will send a message to that particular SP and it will be queued. To avoid this only I thought of remove a SP until the WK is loaded. Once its loaded then add the SP again. – Renien Feb 11 '15 at 17:25
  • And what should happen within the router if the supervisor to route to is not present. That would normally end up with a deadletter? Do you want requests for that worked to go to deadletter during this restart process? In all honesty, you should really handle all of this in the supervisor. The supervisor will know when the worker exists or not. If so, forward the message to the worker. If not, respond to sender that worker not currently available and let the sender figure out what to do next. Or even stash in the supervisor until the worker is back up again and then forward the stash – cmbaxter Feb 11 '15 at 18:17
  • It’s a search engine app. When users search without a delay it should response. WK does the searching part. RT [round-robin-group] [nr-of-instances = 5 (routes) -> SP (5 instance) -> WK (5 Instance). I will restart my WKS one by one so the rest of the WKS will do the job until that particular WK is up. While restarting a single WK, which is under single SP there is big change this SP will get, job request and it will be on queue. If I can remove that particular SP so the messages will be passed to the rest of the SPS and then add SP once WK is up. Is there any way I can handle this situation? – Renien Feb 12 '15 at 04:39
  • Thanks @cmbaxter for your valuable comments. I can't stash it I need to response it ASP with results. Is there anyway I can handle this situation ? To avoid the delay only I thought of remove that particular supervisor and add again so in mean time rest of the supervisors and works will do the job for me. – Renien Feb 12 '15 at 04:45

0 Answers0