2016-06-14 15 views
1

Ich erstelle gerade eine ereignisbezogene Anwendung mit Akka Persistence und dem Cassandra Journal Plugin. Ich habe einige Ansichten, die Ereignisse von mehreren Persistenz-IDs erfassen müssen, daher verwende ich die EventsByTag-Abfragen, um meine Mongodb-Ansichten zu aktualisieren (z. B.).Akka Persistence Cassandra: Zeitstempel! = Offset. Oder wie man Ereignisse nur einmal verarbeitet?

Wenn ich meine Anwendung neu starte, wird die Abfrage erneut abgespielt, daher muss ich den Zustand der Ansichten irgendwie speichern, damit keine Ereignisse wiedergegeben werden, die bereits verarbeitet wurden.

Zuerst plante ich, den Offset des letzten verarbeiteten Ereignisses zu verwenden, da das Cassandra-Plugin TimeUUID intern verwendet und es sollte eindeutig sein. Das Problem dabei ist, dass Akka Journal nur Long-Werte als Offset unterstützt, so dass die TimeUUID wieder in einen normalen Zeitstempel konvertiert wird.

So zB:

2d2504b1-31f8-11e6-af83-9f34c8060f40 und 2d2504b2-31f8-11e6-af83-9f34c8060f40

sowohl Ergebnis in der gleichen Offset, der für mich nutzlos macht in Bedingungen der Bestimmung des letzten verarbeiteten Ereignisses, wenn ich mehrere Ereignisse innerhalb derselben ms habe.

Hat jemand eine Idee, wie man das besser angehen kann?

EDIT


Die CassandraReadJournal bietet eine überladene Version des getEventsByTag Strom, der UUIDEventEnvelopes zurückgibt. Dies enthält den Offset als UUID und nicht Long.

+0

Können Sie einen Weg finden, Ihre Updates idempotent zu machen? Wenn nicht, können Sie mithilfe der Dokumentenversionsverwaltung eine Änderung ablehnen, die bereits angewendet wurde, und versuchen, die Dokumentversion mit der Sequenznummer für die Ereignisse für diese persistenceId auszurichten? – cmbaxter

+0

Ich werde über die Idempotenz nachdenken, aber meine erste Vermutung wäre, dass es in meinem Fall nicht machbar ist. Wie für die Versionierung, einige Ansichten aggregieren Ereignisse von mehreren Persistenz-IDs, so dass ich es nicht als Version verwenden kann (einzelne PersistenceId-Ansichten wäre kein Problem). – thwiegan

Antwort

0

Die CassandraReadJournal bietet eine überladene Version des getEventsByTag Stream, der UUIDEventEnvelopes zurückgibt. Dieser enthält den Offset als UUID und nicht und ist daher einmalig.

+0

Die zurückgegebenen "UUIDs" sind keine echte UUID, sondern ein Unix-Zeitstempel, der in eine UUID gefüllt und somit _nicht_ eindeutig ist. Siehe https://github.com/tfredrich/cassandra-java-driver/blob/master/driver-core/src/main/java/com/datastax/driver/core/utils/UUIDs.java#L160 –