V3 comes with a complete redesign of the patch.
After further analysis we've decided to go with inspecting the incoming journal changes in the case of an initial index re-build.
I'll try to clarify. The scope of
JCR-905 fix should only be for an initial index build.
The initial indexing operation can cause doubles to appear, as some nodes can be seen by a slave before the ADD event has reached it. This happens because of shared storage between cluster nodes.
So, when a slave starts to re-index the repository content, it will include everything (potentially also nodes that is hasn't received a ADD event for yet).
When the index finishes, the repository will continue its startup. A bit later, the cluster component will also initialize and consequently sync. This will pull in the ADD events that were pending in a newer revision, on the master.
The V3 tries to poll the changes before the cluster.sync call, and preemptively generate DELETE events for all the ADD events that it finds on the current workspace.
(this is similar to the
JCR-905 patch, but with a much smaller scope).
Another feature introduced in the patch is to force flush the index after the initial index has been created.
This was artificially done in the original test case (no unit test though) by:
> However, when I debug clusternode 2 and have a breakpoint (i.e., a pause of a few seconds at line 306 of RepositoryImpl.java - just before the clusternode is started), then the resultset contains two results, both with the same UUID.
So forcing the index flush will correctly reproduce the original problem. And I think should be the correct behaviour of the original index creation.
On the other hand, not flushing the index will hide the problem because the indexing queue is smart enough to remove doubles.
But, flushing the index basically invalidates
JCR-905, which is a bit unexpected (see attached patch, by switching the feature flags off).
On the code itself: I guess the AbstractJournal could use a bit of refactoring on the event polling side.