[jira] [Comment Edited] (OAK-6276) expose way to detect "eventual consistency delay"

["Vikas Saurabh (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16029494#comment-16029494 ] 

Vikas Saurabh edited comment on OAK-6276 at 5/30/17 2:39 PM:
-------------------------------------------------------------

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 blocking future job consumption while 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? 


was (Author: catholicon):
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)