Usually, I recommend 1> you configure autocommit on the server. Make it reasonable as in multiple seconds. 2> do NOT commit from the client.
If you must commit from the client, then consider the server.add(docs, commitwithin) call Under no circumstances should you commit from the client IMO except, perhaps, at the very end of the run, but even that's unnecessary if you've configured your autocommit intervals. Here's a long blog on all the autocommit options: http://searchhub.org/2013/08/23/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/ Best, Erick On Fri, Sep 12, 2014 at 8:17 AM, Shawn Heisey <s...@elyograg.org> wrote: > On 9/12/2014 9:10 AM, Joshi, Shital wrote: >> We're updating Solr cloud from a java process using UpdateRequest API. >> >> UpdateRequest req = new UpdateRequest(); >> req.setResponseParser(new XMLResponseParser()); >> req.setParam("_shard_", shard); >> req.add(docs); >> >> We see too many searcher open errors in log and wondering if frequent >> updates from java process are causing it. What commit policy gets used when >> UpdateRequest Solr API is used? Is it opensearcher=true? How do we disable >> it? >> >> This is from log file: >> >> [commitScheduler-16-thread-1] INFO org.apache.solr.update.UpdateHandler ? >> start >> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,soft >> Commit=true,prepareCommit=false} > > There is no commit policy specifically for UpdateRequests. To Solr, > they are simply HTTP calls to the /update handler. > > If you send a commit to Solr with SolrJ, the default will be > openSearcher=true, but you can override it. If you are relying on > autoCommit, the value of openSearcher will be what you define in > autoCommit. An autoSoftCommit always opens a new searcher -- there > would be no point to a soft commit without it. > > Thanks, > Shawn >
