Stop an actor immediately

[Suriyanto Lee]

Hello,

We have an Akka actor system running where some actors can process a short message (<10 secs) and some actors could take up to 20 minutes. At times, users might decide to cancel the process.

We originally implement calling Stop on the actor, but it caused too much lag for user when long message are being processed. Afterwards we modified the actor so that it will perform periodic checks for a cancel flag. The second implementation makes the cancellation to be more responsive, but does not scale well as the number of actors increased.

What is the pattern or best practice in Akka for this case? Is there a way to broadcast an interrupt message to actors for cancelation?

Thanks,

Suriyanto

[√iktor Ҡlang]

A technique I prefer is the following:

case object Continue

case object Cancel

class Worker extends Actor {

  def receive = {

     case Continue =>

       doSmallChunkOfWork()

       self forward Continue

    case Cancel => context stop self

  }

}

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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 akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/groups/opt_out.

--

Cheers,

√

———————

Viktor Klang

Chief Architect - Typesafe

Twitter: @viktorklang

[Suriyanto Lee]

Viktor,

Thanks for the reply. It makes sense and it will simulate Cancel message.

Do you have suggestion on how to do this when the message queue have more than 1 messages? In my case, the message queue can have multiple processing messages, so the Cancel message could be at the end of the queue still and I shouldn't process the next message before the original message is completely processed.

Does this mean that I should change my queue to priority queue that will give priority to Cancel message?

Thanks,

Suriyanto

[√iktor Ҡlang]

Suriyanto,

You switch to pulling in work instead of pushing in work.

[Roland Kuhn]

5 mar 2014 kl. 16:52 skrev Suriyanto Lee <suri...@gmail.com>:

Viktor,

Thanks for the reply. It makes sense and it will simulate Cancel message.

Do you have suggestion on how to do this when the message queue have more than 1 messages? In my case, the message queue can have multiple processing messages, so the Cancel message could be at the end of the queue still and I shouldn't process the next message before the original message is completely processed.

For that you can use Stash:

class Worker extends Actor with Stash {

  val idle: Receive = {

    case NewWork(x) =>

      self forward DoSomeWork(x)

      context.become(active(idFor(x))

  }

  def active(id: Long): Receive = {

    case _: NewWork => stash()

    case DoSomeWork(x) if idFor(x) == id  => self forward DoSomeWork(doWork(x))

    case Cancel => context.become(idle)

  }

  def receive = idle

  …

}

The `id` is necessary not to confuse previous DoSomeWork messages with current ones (after cancellation).

Regards,

Roland

Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Reactive apps on the JVM.
twitter: @rolandkuhn

[Suriyanto Lee]

Thanks, Victor and Roland. As always I learned lots of new things just asking question on this forum.

I'll try to refactor the current code to both. I can probably make less change with the awesome stash technique, but the pull pattern can also help us in balancing the actors work across so no actor will stay idle.

Thanks again.

Suriyanto