Forgot to mention, when a job finishes, it sends poison pill to its parent
unless that job is a master/starter job.
On Friday, February 5, 2016 at 4:06:18 PM UTC, Guido Medina wrote:
>
> Allow your design to have sequential and parallel jobs as the following by
> abstracting it like this:
>
> - Job A: Sequencial.
> - Has task 1 which spawn task 2 and task 2 which spawn task 3 each
> is an actor and each parent -> child/parent -> child
> - Job B: Parallel.
> - Has task 1, task 2 and task 3 all children of Job B.
>
> Guido.
>
> On Friday, February 5, 2016 at 3:59:02 PM UTC, Guido Medina wrote:
>>
>> Divide, conquer and repeat, don't treat each case differently there since
>> you have a parent, for the sake of simplicity I will change the terms and
>> define the following:
>>
>> - 1 actor = 1 transaction.
>> - 1 transaction is a unit of work that either fails of success.
>> - each transaction has sub-transactions (each sub-transaction is a
>> child actor)
>>
>> If you adopt the same pattern your big job will have safe points which
>> should one fail that point will retry, but only that point.
>>
>> It will require you to abstract and repeat the abstraction pattern, it is
>> like a tree with 1 or more children, a leaf could be an ending node or a
>> parent.
>>
>> And actors are perfect for that because you can have millions of them so
>> big numbers are not a problem theoretically speaking.
>>
>> HTH,
>>
>> Guido.
>>
>> On Friday, February 5, 2016 at 3:11:11 PM UTC, Paul Cleary wrote:
>>>
>>> Thanks, yea, I like the Backoff Supervisor, very handy. I tinkered with
>>> that already for handling this kind of scenario.
>>>
>>> The next challenge that follows here is what to do when you are
>>> maintaining state in a database.
>>>
>>> Imagine you have a long running process / job that you are monitoring.
>>>
>>> You might have something like `Job -- 1 to many --> Task`
>>>
>>> As each Task is completed, the Job will update its state in the db (or
>>> the Task can do it, doesn't matter for discussion purposes).
>>>
>>> I feel like there are two models here:
>>>
>>> 1. Pass the Job to the actor and let it run
>>> 2. Pass the Job id to the actor, and let it load its state from the
>>> database to allow it to recover
>>>
>>> Here is what I am thinking:
>>>
>>> class JobActor(job: Job) extends Actor {
>>>
>>> def receive = {
>>> case Process =>
>>> // lets assume the process method starts a child actor processing
>>> results, they will let us know when they are done
>>> job.tasks.foreach(process)
>>>
>>> case Task.Complete(task) =>
>>> db.save(job.complete(task)) pipeTo self
>>>
>>> case akka.status.Failure(e) => throw e
>>> }
>>>
>>> override def preStart() = {
>>> self ! Process
>>> }
>>> }
>>>
>>>
>>>
>>> In this example, we assume that the supervisor will restart. Restarting
>>> from what I understand will pass in the Props, which would be the
>>> *original* job state. Which kinda stinks be cause *all* tasks will be
>>> restarted.
>>>
>>> What we really want is to (as best we can), restart from the *last know
>>> state of the job*
>>>
>>> This is the problem I am trying to tackle.
>>>
>>> In the second solution, it could look something like the following:
>>>
>>> class JobActor(job: Job) extends Actor with Stash {
>>>
>>> def receive = loading
>>>
>>> def loading: Receive = {
>>> case Loaded(job) =>
>>> job.tasks.foreach(process)
>>> unstashAll()
>>> context.become(running, false)
>>>
>>> case akka.status.Failure(e) => throw e
>>> }
>>>
>>> def running = {
>>> case Task.Complete(task) =>
>>> db.save(job.complete(task)) pipeTo self
>>>
>>> case akka.status.Failure(e) => throw e
>>> }
>>>
>>> override def preStart() = {
>>> db.load(jobId).map(Loaded) pipeTo self
>>> }
>>> }
>>>
>>>
>>>
>>> In this solution, we always load the current state from the database
>>> when this actor loads.
>>>
>>> I am curious from a design perspective if this makes sense.
>>>
>>> Sorry for the long question, just sorting through the best way to handle
>>> database failure when managing state across long running processes.
>>>
>>
--
>>>>>>>>>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
