Replay from application-defined sequence number

[krasserm]

See #300 (comment)

[magro]

A general issue might be that the application might load the sequence number from some backend asynchronously. This way it would be forced to await the result. Because this is only done once on startup and therfore might be acceptable, but I still wanted to point at it.

[magro]

Please forget my comment, the application can load the sequence number asynchronously and start the actor once it's loaded / on complete.

[magro]

And just for completeness, I was referring to commit 1703405 :-)

[danbim]

Just for completeness:

When implementing #300 my intention was to make sure that all business logic (and also all the logic to restore an actors state) should be encapsulated within the actor itself. If we load the sequence number asynchronously and pass that into the actor as parameter we would have to externalize that logic. From an application point-of-view I think this is less optimal.

However, I could live with the synchronous version (which is undoubtedly more beautiful / less error-prone) from a framework perspective. Also I guess one could co-locate the loadSequenceNr logic with the business / actor logic by e.g., putting it into the companion object so my initial intention would be met anyways.

Another argument that favours the synchronous version is that error handling for loadSequenceNr is simpler as with the asynchronous version.

So, synchronous version fine with me!

[volkerstampa]

If the sequence number is loaded from some backend, this is not only done once at startup, but each time the actor restarts, i.e. each time an event-replay is required, right? So it depends on the application logic if this should be done frequently or just once at application startup.

[krasserm]

Alternatively (to reading from somewhere), a supervisor stops the actor on exception and a watcher creates a new actor with another sequence number as constructor argument on receiving the termination signal.