Snapshot proposal

[Martin Krasser]

Hello All,

Here's a proposal for a snapshotting API which summarizes current work on branch wip-8-snapshots. Please let me know what you think should you plan to use this feature. I'd like to get some feedback before continuing and merging to master.

Thanks,
Martin

-- 
Martin Krasser

blog:    http://krasserm.blogspot.com
code:    http://github.com/krasserm
twitter: http://twitter.com/mrt1nz

[Volker Stampa]

Hi,

since I also plan to use this feature I had a quick look at the API and can say that it looks pretty convenient for me. I especially like the fact that I do not have to fiddle around with snapshots and sequence numbers when it comes to recovery but a simple

extension.recover(replayParams.allWithSnapshot)

will do. I still have some comments/questions. I only looked at the sample application and not at the actual implementation, so please excuse if some of them look trivial.

- As far as I understand the snapshot is saved to the journal. Is this done in parallel to saving normal Messages or are normal Messages queued and get written once writing the snapshot is finished? Or does this depend on the Journal implementation?

- The SnapshotRequest as well as the Snapshot in SnapshotOffer contain some details like processorId or requestor an eventsourced actor does not care about (as I assume). I wonder if it is a big deal to hide these?

- As far as I understand there is only one snapshot per eventsourced actor. I wonder if it could make sense to support having several snapshots per actor and select which one to base the recovery on. I do not have any requirements for this right now, so I am basically just thinking aloud.

As you can see no serious concerns regarding the API, just some minor comments :-)

Thanks
Volker

--
You received this message because you are subscribed to the Google Groups "Eventsourced User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eventsourced...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ramon Buckland]

Hi Martin, 

On the face of it, it looks quite good. My use of it will be the true test of course, but again. Great work!

Ramon Buckland

ra...@thebuckland.com

[Martin Krasser]

Hi Volker,

Am 09.04.13 18:24, schrieb Volker Stampa:

Hi,

since I also plan to use this feature I had a quick look at the API and can say that it looks pretty convenient for me. I especially like the fact that I do not have to fiddle around with snapshots and sequence numbers when it comes to recovery but a simple

extension.recover(replayParams.allWithSnapshot)

will do.

yes, removing the burden from the user of dealing with sequence numbers during both, snapshot creation and recovery, was a design goal.

I still have some comments/questions. I only looked at the sample application and not at the actual implementation, so please excuse if some of them look trivial.

- As far as I understand the snapshot is saved to the journal. Is this done in parallel to saving normal Messages or are normal Messages queued and get written once writing the snapshot is finished? Or does this depend on the Journal implementation?

This depends on the journal implementation but writing the snapshot concurrently to normal messages makes most sense, especially if snapshots are large. This is supported by the SWRS in the current prototype. With the AWRS, writes are anyway done concurrently.

- The SnapshotRequest as well as the Snapshot in SnapshotOffer contain some details like processorId or requestor an eventsourced actor does not care about (as I assume). I wonder if it is a big deal to hide these?

Agree, would be cleaner to hide them. Shouldn't be a big deal.

- As far as I understand there is only one snapshot per eventsourced actor. I wonder if it could make sense to support having several snapshots per actor and select which one to base the recovery on. I do not have any requirements for this right now, so I am basically just thinking aloud.

This would make definitely sense. Replaying from an older snapshot can avoid issues like those described in this post, for example. It would then make sense to have time-based snapshot selection criteria which would require snapshot timestamps and an extension of ReplayParams.

I added your comments to ticket #8. Thanks for your valuable feedback.

Cheers,
Martin

[Martin Krasser]

FYI: further comments on the snapshot proposal also in this thread

Am 10.04.13 06:43, schrieb Martin Krasser:

[Martin Krasser]

Am 09.04.13 18:50, schrieb Ramon Buckland:

Hi Martin, 

On the face of it, it looks quite good. My use of it will be the true test of course, but again. Great work!

Glad that you like it, thanks for reviewing.

[Greg Young]

So the way we do it is that snapshots are just another stream. This is important because if you want to go back in time you may want n snapshots.

Le doute n'est pas une condition agréable, mais la certitude est absurde.

[Martin Krasser]

Am 10.04.13 11:36, schrieb Greg Young:

So the way we do it is that snapshots are just another stream. This is important because if you want to go back in time you may want n snapshots.

n snapshots will be supported.

[Martin Krasser]

There are now n snapshots stored per processor and you can now apply selection criteria during recovery.

Am 10.04.13 06:43, schrieb Martin Krasser:

Hi Volker,