Thanks for the explanation. Can you elaborate on your last comment
regarding polling as part of the queue consumer logic? Are you
recommending that my consumer attempts to retrieve the node until it is
present?
On 2015-12-07 07:54, Chetan Mehrotra wrote:
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
