[
https://issues.apache.org/jira/browse/OAK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032705#comment-16032705
]
Michael Dürig commented on OAK-6276:
------------------------------------
Maybe we can come up with a less restrictive way of achieving the same by using
"sync points" instead of "revision tokens": you would get a sync point from one
cluster node and then wait on another cluster node for that sync point to
appear. This approach would decouple revisions (which is an implementation
concern) from the synchronisation concern of this issue. Implementation can
underneath still use revisions but are also free to use other means. E.g. doing
a specific commit that is know to not conflict and would so be easily
detectable once it appears on other cluster nodes.
> expose way to detect "eventual consistency delay"
> -------------------------------------------------
>
> Key: OAK-6276
> URL: https://issues.apache.org/jira/browse/OAK-6276
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: api
> Reporter: Stefan Egli
>
> I have a requirement to support an external messaging channel (eg Kafka)
> between Oak-based instances of the same cluster. As part of handling those
> messages the target instance in some cases might have to access data from the
> repository.
> Now with DocumentNodeStore's eventual consistency that data might not
> 'travel' from the source to the target instance as fast as is the case for
> the external message.
> Therefore the need arises to be able to delay such messages (on the target
> instance) until the repository sees (at least) the data the source instance
> wrote when sending off the message.
> This ticket is to equip Oak with any feasible way for higher level code to
> generally speaking detect such an "eventual consistency delay".
> One simple idea that comes to mind is to expose the current _head revision
> vector_ (or that from a particular session, but that might not be required,
> ie be too complicated). The source instance could get the local head revision
> vector, piggyback that on the message, then that could be compared on the
> target instance with its head state. If that turns out to be older, then it
> could do a wait and retry. (Nicer would of course be if there would even be a
> call-back - but in theory that could also be implemented ontop of an
> Observer).
> One means to expose the head revision vector would be via a repository
> descriptor (which on access returns the current value, similar to [how
> discovery-lite does
> it|https://github.com/apache/jackrabbit-oak/blob/2634dbde9aedc2549f0512285e9abee5858b256f/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentDiscoveryLiteService.java#L246]).
> And the format could be normalized as eg {{longs}} (eg {{\[1496071927014,
> 1496071926243]}} (instead of {{\["r15c54d532ec-0-1", "r15c54d532ec-0-2"]}} to
> avoid leaking the revision format explicitly).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
