Thanks. Load is really not a concern. We will be using it only for a handful of admin users and we are ok dedicated a solr server for just this user case. If I have to write a loop to check back if the the updates are written and searcher picked those up, what would that call look like?
Can I set waitSeacher=true or turn off cache autowarms? Anything that make sure the updates are visible before search? Thanks once again. On Tue, Jul 14, 2015 at 3:09 PM, Erick Erickson <erickerick...@gmail.com> wrote: > bq: I have a use case where we have to write data into solr and immediately > read it back. > > This is simply not going to work with frequent updates. Solr > promises Near in NRT, not "real time". > > If nothing else, if you fire the query before autowarming is completed. In > this > case you'll sometimes get the doc and sometimes not because you'll > get a search on the old version of the index before the update. And if you > fire > soft commits rapidly, you'll exceed maxWarmingSearchers > and get warnings in the log.. which will also not return you the new docs. > > You'll have to revisit this requirement. Either you'll have to build in a > retry > loop, some other kind of delay or change the requirement. > > And under heavy indexing load this will not be performant. > > Best, > Erick > > > On Tue, Jul 14, 2015 at 11:19 AM, Bhawna Asnani <bhawna.asn...@gmail.com> > wrote: > > Hi, > > I have a use case where we have to write data into solr and immediately > > read it back. > > The read is not get by Id but a search call. > > > > I am doing a softCommit after every such write which needs to be visible > > immediately. > > However sometimes the changes are not visible immediately. > > > > We have a solr cloud but I have also tried sending reads, writes and > > commits to cloud leader only and still there is some latency. > > > > Has anybody tried to use solr this way? > > > > -Bhawna >
