I believe that there's a configuration option that'll make on-deck searchers be used if they're needed even if they're not fully warmed yet. You might try that option and see if it doesn't solve your 503 errors.
Thanks, Greg On Feb 18, 2014, at 9:05 PM, Erick Erickson <erickerick...@gmail.com> wrote: > Colin: > > Stop. Back up. The automatic soft commits will make updates available to > your users every second. Those documents _include_ anything from your "hard > commit" jobs. What could be faster? Parenthetically I'll add that 1 second > soft commits are rarely an actual requirement, but that's your decision. > > For the hard commits. Fine. Do them if you insist. Just set > openSearcher=false. The documents will be searchable the next time the soft > commit happens, within one second. The key is openSearcher=false. That > prevents starting a brand new searcher. > > BTW, your commits are not failing. It's just that _after_ the commit > happens, the warming searcher limit is exceeded. > > You can even wait until the segments are flushed to disk. All without > opening a searcher. > > Shawn is spot on in his recommendations to not fixate on the commits. Solr > handles that. Here's a long blog about all the details of durability .vs. > visibility. > http://searchhub.org/2013/08/23/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/ > > You're over-thinking the problem here, trying to control commits with a > sledgehammer when you don't need to, just use the built-in capabilities. > > Best, > Erick > > > > On Tue, Feb 18, 2014 at 10:33 AM, Colin Bartolome <co...@e-e.com> wrote: > >> On 02/18/2014 10:15 AM, Shawn Heisey wrote: >> >>> 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 >>> >>> >> We use the automatic soft commits to get search index updates to our users >> faster, via Near Realtime Searching. We have the updateLog enabled. I'm not >> worried that the Solr side of the equation will lose data; I'm worried that >> the communication from our web servers and scheduled jobs to the Solr >> servers will break down and nothing will come along to make sure everything >> is up to date. It sounds like what we're picturing is not currently >> supported, so I'll file the RFE. >> >> Will upgrading to 4.6.1 help at all with this issue? >>
