OK, I'll ask the elephant in the roomÂ.
What is the difference between the new UpdateHandler from Mark and the SOLR-RA? The UpdateHandler works with 4.0 does SOLR-RA work with 4.0 trunk? Pros/Cons? On 8/14/11 8:10 PM, "Nagendra Nagarajayya" <nnagaraja...@transaxtions.com> wrote: >Naveen: > >NRT with Apache Solr 3.3 and RankingAlgorithm does need a commit for a >document to become searchable. Any document that you add through update >becomes immediately searchable. So no need to commit from within your >update client code. Since there is no commit, the cache does not have >to be cleared or the old searchers closed or new searchers opened, and >warmed (error that you are facing). > >Regards > >- Nagendra Nagarajayya >http://solr-ra.tgels.org >http://rankingalgorithm.tgels.org > > > >On 8/14/2011 10:37 AM, Naveen Gupta wrote: >> Hi Mark/Erick/Nagendra, >> >> I was not very confident about NRT at that point of time, when we >>started >> project almost 1 year ago, definitely i would try NRT and see the >> performance. >> >> The current requirement was working fine till we were using >>commitWithin 10 >> millisecs in the XMLDocument which we were posting to SOLR. >> >> But due to which, we were getting very poor performance (almost 3 mins >>for >> 15,000 docs) per user. There are many paraller user committing to our >>SOLR. >> >> So we removed the commitWithin, and hence performance was much much >>better. >> >> But then we are getting this maxWarmingSearcher Error, because we are >> committing separately as a curl request after once entire doc is >>submitted >> for indexing. >> >> The question here is what is difference between commitWithin and commit >> (apart from the fact that commit takes memory and processes and >>additional >> hardware usage) >> >> Why we want it to be visible as soon as possible, since we are applying >>many >> business rules on top of the results (older indexes as well as new one) >>and >> apply different filters. >> >> upto 5 mins is fine for us. but more than that we need to think then >>other >> optimizations. >> >> We will definitely try NRT. But please tell me other options which we >>can >> apply in order to optimize.? >> >> Thanks >> Naveen >> >> >> On Sun, Aug 14, 2011 at 9:42 PM, Erick >>Erickson<erickerick...@gmail.com>wrote: >> >>> Ah, thanks, Mark... I must have been looking at the wrong JIRAs. >>> >>> Erick >>> >>> On Sun, Aug 14, 2011 at 10:02 AM, Mark Miller<markrmil...@gmail.com> >>> wrote: >>>> On Aug 14, 2011, at 9:03 AM, Erick Erickson wrote: >>>> >>>>> You either have to go to near real time (NRT), which is under >>>>> development, but not committed to trunk yet >>>> NRT support is committed to trunk. >>>> >>>> - Mark Miller >>>> lucidimagination.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >
