[
https://issues.apache.org/jira/browse/OAK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031125#comment-16031125
]
Stefan Egli commented on OAK-6276:
----------------------------------
[~catholicon], thanks! Exposing an opaque string - similar to checkpoints - and
providing a {{compareWithHead}} method sounds perfectly fine to me. I wonder if
we'd want to actually make it another checkpoint type (a non-persisted,
volatile checkpoint?)
Re sidenote 1: agreed, mixed message-producer delays that end up at the same
message-consumer would have the potential to delay each other. But I'd leave
that as an upper-level problem to solve, unrelated to this here.
Re sidenote 2: I would assume that this mechanism should store anything and
that it shouldn't have to read anything - thus shouldn't be affected by GC in
any way. It should be a pure comparison based on whatever opaque string is
returned ideally. Or am I missing something?
Re sidenote 3: exception / null, anything would be fine I guess. We'd have to
clearly state it though, yes.
Re sidenote 4: good point. Afaik multiplexing so far contained only 1
modifiable node store (and perhaps n read-only ones). As long as that holds we
should be fine. If we support multiple modifiable node stores then perhaps the
implementation of returning such an opaque volatile checkpoint becomes a bit
more tricky. But I think it could still be a vector of some kind?
> 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)
