`PersistenceFailure` is a notification about a problem in the journal actor, so a restart of the processor by a supervisor wouldn't help much here. It's actually the journal that must be restarted by a supervisor (as done by [`SyncWriteJournal`](https://github.com/eligosource/akka/blob/wip-3641-storage-plugin-apis-krasserm/akka-persistence/src/main/scala/akka/persistence/journal/SyncWriteJournal.scala#L28) if `write` throws an exception). `AsyncWriteJournal` OTOH delegates fault handling to implementation classes (e.g. this could be even located in the async storage backend driver) - I'll remove the [erroneously placed](https://github.com/eligosource/akka/blob/wip-3641-storage-plugin-apis-krasserm/akka-persistence/src/main/scala/akka/persistence/journal/AsyncWriteJournal.scala#L45)`throw e` in `AsyncWriteJournal` with the next commit. 

A processor can still decide to throw an exception (for whatever reason) when receiving this failure message. But it likely may want to inform the sender to re-send the message, or trigger some application-specific compensations. The latter is also the reason why a generic failure reply from the journal to the sender is not flexible enough.