Hi,
it always is a good idea to have a single node in charge of being the "master" and be the only node in charge of indexwriting, as having multiple nodes writing at the same time leads to lock contention issues.
However the Hibernate Search library version 4.x does not implement an automatic master election protocol, if you need that level of guarantees I'd suggest you use a JMS backend: with JMS you can choose to either make messages persistent - so that when the master node is down messages aren't lost and can be processed as soon as it's restored - or you can let your JMS provider implement an highly available master.
With Hibernate Search 5 in combination with Infinispan I'm working at an automatic election protocol, but I can't promise yet as when it might be ready.
Quote:
How can I have the master rebuild the index in background and swap fresh index when complete?
Not implemented: we generally expect you to rebuild the index when it was lost, so there is no swapping logic. But even so, as soon as your index is rebuilt, queries will work again. Technically queries will work even with an incomplete index, but will return incomplete results.
Quote:
Is there a way to configure hibernate to default back to slow lookups in case index or cluster communication is lost?
What do you mean by "slow lookups"?
On the vmnet adapter, that's a question for the JGroups experts mailing list; my guess is that your routing isn't setup to multicast packets to this machine, or maybe the ip_ttl is too low? You might want to use a TCP stack rather than the default UDP, and then use a different DISCOVERY protocol than the default (which relies on multicast packets). You could use TCPPING or JDBC_PING.. I wrote JDBC_PING myself as I assume for people using Hibernate+JGroups it's handy to delegate the discovery aspect to the shared database.