>
> Could this be due to caching? I have tried to disable all in my solrconfig.
If you mean Solr caches ? NO .
Solr caches live the life of the searcher.
So new searcher, new caches ( possibly warmed with updated results) .
If you mean your application caching or browser caching, you should veri
Bhawna,
I think you need to reconcile yourself to the fact that what you want to
achieve is not going to be possible.
Solr (and Lucene underneath it) is HEAVILY optimised for high read/low
write situations, and that leads to some latency in content reaching the
index. If you wanted to change this
Thanks, I tried turning off auto softCommits but that didn't help much. Still
seeing stale results every now and then. Also load on the server very light. We
are running this just on a test server with one or two users. I don't see any
warning in logs whole doing softCommits and it says it succe
On 7/20/2015 9:29 AM, Bhawna Asnani wrote:
> Thanks for your suggestions. The requirement is still the same , to be
> able to make a change to some solr documents and be able to see it on
> subsequent search/facet calls.
> I am using softCommit with waitSearcher=true.
>
> Also I am sending reads/wr
ed
> >> > frequently under application control (vs. auto commit) and we turned
> off
> >> > all auto-warming and most of the caching.
> >> >
> >> > There is scant documentation in the new Solr reference (
> cwiki.apache.org
> >> ),
> >> &
lrCaching
>> >
>> > Just a thought: would true be helpful
>> > here?
>> >
>> > Also, since you have just inserted the documents, it sounds like you
>> > probably could search by ID ...
>> >
>> > -Original Message-
&
ps://wiki.apache.org/solr/SolrCaching
> >
> > Just a thought: would true be helpful
> > here?
> >
> > Also, since you have just inserted the documents, it sounds like you
> > probably could search by ID ...
> >
> > -----Original Message-
> > Fr
inserted the documents, it sounds like you
> probably could search by ID ...
>
> -Original Message-
> From: Shawn Heisey [mailto:apa...@elyograg.org]
> Sent: Tuesday, July 14, 2015 6:04 PM
> To: solr-user@lucene.apache.org
> Subject: Re: SOLR nrt read writes
>
> On
?
Also, since you have just inserted the documents, it sounds like you probably
could search by ID ...
-Original Message-
From: Shawn Heisey [mailto:apa...@elyograg.org]
Sent: Tuesday, July 14, 2015 6:04 PM
To: solr-user@lucene.apache.org
Subject: Re: SOLR nrt read writes
On 7/14/2015 12:19
On 7/14/2015 12:19 PM, Bhawna Asnani wrote:
> 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 ch
Ahh, good point about setting waitSearcher=true, I should have thought of that.
Although the default is set to "true", so unless you're doing
something different
that should be set already.
Look at your Solr logs and see if you find messages about "too many warming
searchers" or some such. IN that
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
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 t
13 matches
Mail list logo
