0

According to the Akka docs, a DeadLetterActorRef is:

the default implementation of the dead letters service to which Akka routes all messages whose destinations are shut down or non-existent.

If I wanted to "tap into" dead letters sent after an actor is terminated, do I just somehow "hook" this DeadLetterActorRef and get it to pass me everything it receives? Or do I subclass it? Or do I do something else entirely different? Either way, how?

smeeb
  • 27,777
  • 57
  • 250
  • 447

1 Answers1

2

You can listen on the event stream for the dead letter events. Something like this:

import akka.actor._

class DeadLetterListener extends Actor {
  override def preStart {
    context.system.eventStream.subscribe(self, classOf[DeadLetter])
  }

  override def postStop {
    context.system.eventStream.unsubscribe(self)
  }

  def receive = {
    case DeadLetter(msg, from, to) =>
      //handle the deadletter here
  }
}
cmbaxter
  • 35,283
  • 4
  • 86
  • 95
  • Thanks @cmbaxter (+1) - then when/where does my code ever need to interact with `DeadLetterActorRef`, and why? – smeeb Jun 01 '15 at 19:30
  • 1
    It doesn't "have" to interact with it at all. But you could end up coming up with cases depending on your requirements. Maybe you have a particular use case that says that if a particular actor is not available that you store it's messages for a bit until it comes back up. You could use something like this to make that happen. For me, I instrumented this listener to to keep track of incidences of deadletters as a health indicator for our system. If the incidence rate of deadletters ticks up it means that something is probably wrong in our system – cmbaxter Jun 01 '15 at 19:34
  • Thanks again @cmbaxter (+1) - last followup I promise! So when you say "*Maybe you have a particular use case that says that if a particular actor is not available that you store it's messages for a bit...*". So are you saying that `DeadLetterActorRef` is persistent, or that it exposes an API for recovering historical dead letters? Can you just clarify what you mean here a bit more? Thanks again! – smeeb Jun 01 '15 at 19:59
  • 1
    No it's not persistent. All that listener is is a hook. If you want something more you have to do it all yourself. – cmbaxter Jun 01 '15 at 20:03
  • Thanks, I think I get it now (+1 again @cmbaxter), can you please confirm I understand: One would normally not interact with `DeadLetterActorRef` directly per se. Instead, it would be more useful to subclass it, have the subclass do exactly what you need it to do (persist messages, etc.), and then have the rest of your actor system interact with the *subclass*. **Am I correct here?** Thanks again! – smeeb Jun 01 '15 at 20:06
  • 1
    You are correct in that you don't normally have to interact with dead letters but not correct in that if you do you subclass the dead letter ref actor. The approach I outlined listens to the stream of dead letters and is not directly related to the dead letter ref itself structurally. From there though, yes, if you want to do anything meaningful with that stream of data you will have to roll it yourself. – cmbaxter Jun 01 '15 at 20:17
  • Ehhh, so I feel **really** bad asking yet another followup (at least I keep +1-ing you, @cmbaxter!), but then I'm still not comfortable that I understand `DeadLetterActorRef`. If you **don't** subclass this actor, then what **would** you do to interact with it, and why? For simplicity's sake, let's scrap your `DeadLetterListener` which listens to the event stream. I appreciate and understand it, but I think it's confusing my understanding of `DeadLetterActorRef`. Thoughts? Thanks again!!! – smeeb Jun 01 '15 at 20:19