I have a setup of Hibernate Search with Jgroups backend, and have 1 master with up to 3 slaves. The index is stored using Infinispan with no filestore (I have a relatively small index). The whole system sits behind a load balancer, and apart from the jgroups master/slave setting, the nodes are identical. If the master node happens to go down, would the search index not be updated until it goes up again?

hi, yes that's correct. the master is a critical component in this configuration.
If that's a problem I'd suggest to use JMS with a failover mode, or help me to test HSEARCH-882 as soon as I we release the next alpha tag.. this one should take a lot of configuration complexity away and just do "the right thing"

In a master/slave configuration, if you rebuild the index using a MassIndexer that wipes and recreates the index on the master, are the slaves still online and searchable in their full capacity? I'm trying to understand is that the only way to use the MassIndexer on a large scale of records while being able to keep the index completely online for user searches until the MassIndexer can be modified to support update/removal mechanics described in HSEARCH-1032.

That looks like an improvement we could make. So you expect to run the MassIndexer regularly in production? Shouldn't be needed generally.

If you allow Hibernate to manage the insert/update/deletes from the database, absolutely. But in the cases where the data is managed outside of Hibernate and all Hibernate offers is a database agnostic solution for a web application that has read only access to this information, then the MassIndexer appears to be the only viable way to keep the Lucene indexes aligned with the data in the database.

I have considered moving the TSQL programs from the database into Java-code that leverages Hibernate in the long-term but we have some prior milestones that must be met before that can be made a reality and some research needed to manage Hibernate connected to multiple databases.

understood. Did you consider using the non-automated approach? We describe the "flush-to-indexed" technique which provides much more control on how the operations are performed:

http://docs.jboss.org/hibernate/search/4.3/reference/en-US/html_single/#search-batchindex-flushtoindexes

It is somewhat slower, but that could be a good thing compared to saturating all your CPUs if you want to serve requests at the same time.

Also you could track or help with https://hibernate.atlassian.net/browse/HSEARCH-1032

I just sent some proposals to the mailing list:
http://lists.jboss.org/pipermail/hibernate-dev/2013-July/010135.html

(possible follow ups: http://search.jboss.org/#!q=%22HSEARCH-1032%22&project=hibernate&mailList=dev )