I was wondering what the thought was on the current design of the JCR index and clustering was. The topology of one writer and multiple readers on a shared GFS is not a very standard Lucene topology and I suspect performance is suboptimal. More nominal are each node having a separate copy of the index and writes being passed via messaging and/or replicated via rsync. Are there plans to support a more standard lucene topology? If not, why not? If so, when?
Andy ! You are everywhere !
To answer your question I agree that this would be a good configurable alternative to have.
It depends if you care about "consistency" vs "eventual consitency", most of the time eventual consitency should be enough for searching but so far eXo JCR has been focused on being to find documents immediately after they are created. Getting rid of shared network requirement would definitely remove one hurdle for clustering setup.
I didn't hear such a plan in eXo JCR roadmap and we haven't pushed for this feature, but contributions are always welcome And a JIRA in https://issues.jboss.org/browse/EXOJCR would be a good start.
This surprises you?
With a transactional locking you could have actual consistancy or darn near close.
The shared FS bit doesn't scale to the same scale as other people using Lucene who have similar requirements:
while Salesforce does it more like Exo's setup, it does it with I imagine a lot more beef per system than is common and a lot of segmentation "pod"s:
I'll post the feature request. I'll note your response to the team I'm working with.
Thank for sharing ideas, it is always priceless especially when it comes from the community, I will read carefully all your documents and JIRAs. FYI we are aware of the limitations of our clustering design as you can see here https://issues.jboss.org/browse/EXOJCR-1080 and we work hard on this task for several months.
The main reason why we decided to use a shared file system instead of having dedicated indexes for each node, is because we wanted to be able to add new nodes to the cluster dynamically which is not really easy when your new node doesn't have its own copy of indexes. And the reason why we have one node in RW mode (the coordinator) and the other nodes in RO mode, it is mainly to avoid relying on lock mechanism proposed by shared file system which limits the risk of corrupting the indexes and to keep a consistent state of the indexes.
In JCR 1.14.0 thanks to EXOJCR-1080, we will allow all nodes to have their own copy of indexes since we improved the indexes recovery which is mainly needed when you add a new node to the cluster or a node has left the cluster during a certain period of time so its indexes are not up to date anymore and should be recreated. So now you have the choice between two options: either the node re-indexes the database if it the db is not too big of course (which can be done in a reasonable period of time since we improved the indexing a lot, as you can see here https://issues.jboss.org/browse/EXOJCR-1104, it is now multi-threaded and optimized for RDBMS) or it gets the indexes content from the coordinator.
I hope it helps,