RaftActor implements time-sensitive messaging exchange, but it is also subclassed to provide subclass operations.

When the subclass is targeted with a lot of messages, this can lead to timeouts in the RAFT underlay – hence potentially disrupting stability.

Akka provides a way to divide classes into two:

• make important messages implement akka.dispatch.ControlMessage
• use one of ControlAwareMailboxes

ControlAwareMailboxes use two internal queues, giving priority to delivering messages which are instanceof ControlMessage and delivering other messages only when no ControlMessage is present.

This way we can ensure that the RAFT algorithm operates isolated from any floods incurred by the implementation above, leading to better stability.

Performance impact and interactions with persistence need to be evaluated before this becomes our default.