Hi David, To elaborate a bit on what Vikas and Davide said
Oak has a MVCC storage model which is eventually consistent. So any change made on one cluster node would not be immediately visible on other cluster nodes. Instead each node would periodically poll for changes in the backend store (Mongo for above case) and then updates it head revision. After that only changes made in those revisions would be "visible" to that cluster node. So in above setup if on cluster node N1 you add a node and then that information is communicated to other cluster node N2 outside of Oak (here a message queue) and then other cluster nodes reacts to that then there is a chance that such a change would not have became visible on that cluster node. Currently there is no deterministic way other than introducing polling as part of queue consumer logic Chetan Mehrotra On Mon, Dec 7, 2015 at 7:20 PM, Vikas Saurabh <[email protected]> wrote: > On Mon, Dec 7, 2015 at 7:14 PM, David Marginian <[email protected]> wrote: >> Yes, each node however is referencing the same mongo instance. Is there a >> way to tell jackrabbit to grab the document from mongo instead of using the >> cluster cache (assuming that is what's going on). > > Each cluster node has a thread (background read thread) which, in > crude sense, absorbs changes from other nodes. Although, simultaneous > conflicting writes are avoided but a state of node that's visible to > layers above (Jcr, etc) don't get to see changes from other nodes > until background read is done with absorbing changes from other nodes. > > Thanks, > Vikas
