[
https://issues.apache.org/jira/browse/OAK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16029494#comment-16029494
]
Vikas Saurabh commented on OAK-6276:
------------------------------------
bq. If that turns out to be older,
I think there is no semantics of any strict ordering wrt node states. And, in
any case, all we want to see if such a state is visible or not. Some derived
propossal/blabber below.
Imo, exposing a semantic of revision might not be a good idea. At the end of
the day, all we want is message-producer to be able to pass on a token to
message-consumer. Message-consumer should be able to then call some exposed
util method to say something like {{waitUntilTokenVisible(token)}} (or maybe a
callback/future/something-fancy).
The token can simply be a opaque string - and nodestores could very well choose
to pass along revision id (on seg-tar, it might be useful to actually send out
a journal log type entry). Usage of that string, otoh, could only be done to
peek if such a state is visible.
Internally, I guess all nodestores can do their internal
{{!getRootAtToken().isEmpty())}} to check for visibility.
For scheduling/callback/waits, I think the stores should be able to cook up
something (I don't even have a hand-wavy idea atm).
To expose these facilities, I guess a utility method that takes session and
does the task would be sufficient e.g. {{static String
getVisibilityTokenFor(session)}} or {{static isTokenVisible(session, token)}.
----
Sidenotes:
# wrt to kafka, btw, I'm assuming multiple job-producers - I'm not sure how
would we store offsets of processed jobs without hindering job consumption by
waiting to see valid state on the job that got picked.
# What we're trying is having a soft-checkpoint. I'm not sure of how can we
handle a job that was sent on a very old revGC-ed/compacted to be processed
(and do we even want to??)
# Would seg-tar throw UnsupportedException on the facilities we expose here?
# Haven't thought this through - but, how does multiplexing node store play
along?
> 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)
