On 02/17/2014 09:46 PM, Shawn Heisey wrote:
I think I put too much information in my reply. Apologies. Here's the
most important information to deal with first:
Don't send hard commits at all. Configure autoCommit in your server
config, with the all-important openSearcher parameter set to false.
That will take care of all your hard commit needs, but those commits
will never open a new searcher, so they cannot cause an overlap with the
soft commits that DO open a new searcher.
Thanks,
Shawn
I'll describe a bit more about our setup, so I can say why I don't think
that'll work for us:
* Our web servers send update requests to Solr via a background thread, so
HTTP requests don't have to wait for the request to complete.
* That background thread has a small chance of failing. If it does, the
update request won't happen until our "hard commit" job runs.
* Other scheduled jobs can send update requests to Solr. Some jobs
suppress this, because they do a lot of updating, instead relying on the
"hard commit" job.
* The "hard commit" job does a batch of updates, waits for the commit to
complete, then sets some flags in our database to indicate that the
content has been successfully indexed.
It's that last point that leads us to want to do explicit hard commits. By
setting those flags in our database, we're assuring ourselves that, no
matter if any other steps failed along the way, we're absolutely sure the
content was indexed properly.
If there's no other way to do this, I'm okay with filing an RFE in JIRA
and continuing to ignore the "multiple on-deck searchers" warning for now.
