Re: Problems of deleting documents from Solr

Hi Jeff, You can  delete either by unique id or by a query. It seems that you want to delete all documents having category of monitor. cat:monitor http://wiki.apache.org/solr/UpdateXmlMessages#A.22delete.22_by_ID_and_by_Query - Original Message - From: Jeff Zhang To: solr-user@lucene.

Re: fq parameter with partial value

I'm a bit confused here. What is the difference between CATEGORY and CATEGORY_TOKENIZED if I just do a copyField from what field to another? And how can I search only for Restaurant (fq= CATEGORY_TOKENIZED: Restaurant). Shouldn't I have something like Hotel, if I want this to work. And from what I

Re: Autocomplete(terms) middle of words

I've already use nutch trunk 4.0. I have problem with space. -- View this message in context: http://lucene.472066.n3.nabble.com/Autocomplete-terms-middle-of-words-tp2878694p2888940.html Sent from the Solr - User mailing list archive at Nabble.com.

Re: Problems of deleting documents from Solr

Hi Jeff, If you run the optimize command after deletion, all documents marked as deleted will be expunged from the index. Keep in mind that another way to update a document is to just re-add it with the new values. If you use uniqueKey (defined in schema.xml), Solr will make sure there are n

Re: Has NRT been abandoned?

--- On Sun, 5/1/11, Robert Muir wrote: > Hi, I don't think it means that. keep an eye on > https://issues.apache.org/jira/browse/SOLR-2193, you > can set yourself > as a Watcher to receive updates. Ah I see. Thank you.

Re: Has NRT been abandoned?

Nagendra, This looks interesting. Does Solr-RA support: 1) facet 2) Boost query such as {!boost b=log(popularity)}foo Thanks Andy --- On Sun, 5/1/11, Nagendra Nagarajayya wrote: > From: Nagendra Nagarajayya > Subject: Re: Has NRT been abandoned? > To: solr-user@lucene.apache.org > Date: Sund

Problems of deleting documents from Solr

Hi all, I want to update some document, so first I delete these document by invoking command "java -Ddata=args -Dcommit=yes -jar post.jar "monitor" The result is that I can not search the deleted documents but I can still see the terms of these document in http://localhost:8983/solr/admin/schema.j

Re: Searching performance suffers tremendously during indexing

http://lucene.apache.org/java/3_0_3/api/contrib-misc/org/apache/lucene/index/BalancedSegmentMergePolicy.html Look in solrconfig.xml for where MergePolicy is configured. On Sun, May 1, 2011 at 6:31 PM, Lance Norskog wrote: > Yes, indexing generally slows down querying. Most sites do indexing in >

Re: solr sorting problem

Two scenarios: 1) you call the indexing API but do not call 'commit'. This makes data visible to searching. 2) the default solrconfig has HTTP caching turned on. So you redo the search url, and you get the old result. This is really really annoying. And you have to change the configuration to speci

Re: Searching performance suffers tremendously during indexing

Yes, indexing generally slows down querying. Most sites do indexing in one Solr and queries from another. The indexing system does 'merging', which involves copying data around in files. With 10g allocated to a 1g load, the JVM is doing a lot more garbage collection that it would with a 1.5g alloc

Re: Searching performance suffers tremendously during indexing

Couple of things. One you are not swaping which is a good thing. Second (and I am not sure what delay you selected for dstat, I would assume the default of 1 second) there is some pretty heavy write activity like this: 26 1 71 2 0 0 |4096B 1424k| 0 0 | 719 415 | 197M 11G|1.00

Re: Searching performance suffers tremendously during indexing

Thanks for the tool recommendation! This is the dstat output during commit bombardment / concurrent search requests: total-cpu-usage -dsk/total- ---paging-- ---system-- swap--- --io/total- ---file-locks-- usr sys idl wai hiq siq| read writ| in out | int csw | used free| read w

Re: Has NRT been abandoned?

On Sun, May 1, 2011 at 11:28 AM, Andy wrote: > Hi, > > I read on this mailing list previously that NRT was implemented in 4.0, it > just  wasn't ready for production yet. Then I looked at the wiki > (http://wiki.apache.org/solr/NearRealtimeSearch). It listed 2 jira issues > related to NRT: SOLR

Re: Searching performance suffers tremendously during indexing

If you are on linux, I would recommend two tools you can use to track what is going on on the machine, atop ( http://freshmeat.net/projects/atop/ ) and dstat ( http://freshmeat.net/projects/dstat/ ). atop in particular has been very useful to me in tracking down performance issues in real time

Re: Has NRT been abandoned?

Hi Andy: I have a solution for NRT with Solr 1.4.1. The solution uses the RankingAlgorithm as the search library. The NRT functionality allows you to add documents without the IndexSearchers being closed or caches being cleared. A commit is not needed with the document update. Searches can ru

Has NRT been abandoned?

Hi, I read on this mailing list previously that NRT was implemented in 4.0, it just wasn't ready for production yet. Then I looked at the wiki (http://wiki.apache.org/solr/NearRealtimeSearch). It listed 2 jira issues related to NRT: SOLR-1308 and SOLR-1278. Both issues have their resolutions s

Re: Searching performance suffers tremendously during indexing

Committing too frequently is very costly, since this calls fsync on numerous files under-the-hood, which strains the IO system and can cut into queries. If you really want to commit frequently, turning on compound file format could help things, since that's 1 file to fsync instead of N, per segment

Re: solr sorting problem

Hello, I got over that problem but now i am facing a new problem. Indexing works but search does not. I used the following line in the schema:- and I'm trying to use the default "alphaOnlySort" in the sample schema.xml. Database is MySQL, there is a column/field named ColXYZ My data-

Re: Searching performance suffers tremendously during indexing

Thanks Craig, I'm beginning to think that frequent commits are causing the performance degradation, even though there shouldn't be any *concurrent* commits in our system. There's just one indexing thread per Solr core, waitFlush/waitSearcher are set to true. For now I'd pretty much rule out RAM s

Re: solr 3.1 - TikaEntityProcessor

thanks koji :), it works-- View this message in context: http://lucene.472066.n3.nabble.com/solr-3-1-TikaEntityProcessor-tp2883520p2885679.html Sent from the Solr - User mailing list archive at Nabble.com.