I have a job running some times a day. Between these times the messages are stashed.
How do you handle this stash if the server needs a restart? Maybe stashing is not what should be used?
The answer likely depends on your use case. If you're primarily concerned about controlled shutdowns, then you could message the actor before the shutdown to either process the stashed messages early, or to persist them into temporary storage until the actor restarts.
This wouldn't do you much good if the actor system crashes. To protect against this, you can simply save the message to a database, text file, or another storage mechanism of your choice, instead of using the Stash. Create a child actor ("storage actor" below) to handle the IO for you (as that is a potentially risky operation).
The parent actor has (at a minimum) two states: Listening
and Processing
. While Listening
, it sends any messages that arrive to the storage actor which writes it into the repository. When your job runs, then the actor Become()
s Processing
.
When the parent actor's state changes to Processing
the parent messages the storage actor and requests that all stored messages be sent back. These are received and processed appropriately. When the storage actor has sent all of the messages it has, it sends a Complete
message. The parent actor then Become()
's Listening
again, and the cycle starts over.
In other cases, you may want to use Akka.Persistence. That's too big of a topic to go into here, but you can find the information you need to make an informed decision here: http://bartoszsypytkowski.com/how-akka-net-persistence-works/
The other thing I would consider is whether this process actually requires batching. Some valid batch use cases exist in message systems, especially when interfacing with other non-message based systems, but if this is used internally in your actor system, my first action would be to see if the process could be done real-time.