On 2/18/2014 10:59 AM, Colin Bartolome wrote:
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 you want to be completely in control like that, get rid of the
automatic soft commits and just do the hard commits.
I would personally choose another option for your setup -- get rid of
*all* explicit commits entirely, and just configure autoCommit and
autoSoftCommit in the server config. Since you're running 4.x, you
really should have the transaction log (updateLog in the config)
enabled. You can rely on the transaction log to replay updates since
the last hard commit if there's ever a crash.
I would also recommend upgrading to 4.6.1, but that's a completely
separate item.
Thanks,
Shawn
