On Mon, Dec 15, 2014 at 7:38 PM, David <[email protected]> wrote:
>
> Hello,
>
> Given a pool router  (PR) containing 5 workers(Wn) which connect to the
> database and a client actor (C) which uses and watches PR.
>
> I would like to implement a fault tolerance strategy as follows:
>
> 1. When the database goes down, all Wn will eventually stop which will
> cause PR to stop.
> 2. When C sees PR terminate, C should periodically ask PR's parent for a
> new PR actorRef.
> 3. PR, when asked to create a new pool of Wn, will create this pool.
>
> My questions are:
>
> 1. Does this strategy fit into the Actor model for database retries?  I
> would like to have C automatically "become" either "databaseUp" or
> "databaseDown" and automatically switch to databaseUp when the database
> comes up.
>

I assume you have a mechanism to query DB for its liveness. Then when in
"databaseDown" state you can schedule a periodic message upon which
retrieval an actor tries to open and verify the connection to the DB. Upon
success actor can change its state to "databaseUp".


> 2. I want PR, when it tries to create the pool, to detect whether the
> database is up or down and only return the PR actorRef when all underlying
> workers have been properly initialized.  What is the best way to do this?
> This sounds like some blocking is involved.
>

You can Broadcast
<http://doc.akka.io/docs/akka/2.3.8/scala/routing.html#Broadcast_Messages> a
status message to each of the routees. Routee would check the DB connection
and send a reply to the sender. Now the tricky part (as you correctly
noticed) is not blocking when waiting for all the answers from routees. You
can become(waitingForStatusCheck(routeesToCheck)) and then do
become(waitingForStatusCheck(routeesToCheck - 1)) upon receive of every
status check.


>
> Currently, each Wn will stop which will cause the pool to stop which will
> cause a Terminate message in client C.
> C will ask PR's parent to create a new pool since the old one stopped but
> only return a new Pool when all of the underlying workers have successfully
> connected back to db.
>
> Thanks
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Martynas Mickevičius
Typesafe <http://typesafe.com/> – Reactive
<http://www.reactivemanifesto.org/> Apps on the JVM

-- 
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to