Re: Merge and commit behaviour - changed between 2.4 and 2.9?

Well, the merges continue running and altering the segments files, but the changes done by the merges are not committed until the app calls commit (or closes the IW). Ie, no new segments_N file is written due to merging after the last commit. Mike On Tue, Oct 5, 2010 at 6:45 PM, Mark Harwood wr

Re: Merge and commit behaviour - changed between 2.4 and 2.9?

OK. I'll double check the reports. So presumably when merges occur outside of transaction control (post commit) the post-merge update of the segments_N file is managed safely somehow? I can see the logic in continuing file changes outside of transaction control because the document updates are s

Re: Numeric range query not returning results

Lucene doesn't (as far as I know) support pure negative queries. Have you tried adding the MatchAllDocsQuery to your BQ? See: http://lucene.apache.org/java/2_4_0/api/org/apache/lucene/search/MatchAllDocsQuery.html

Re: Merge and commit behaviour - changed between 2.4 and 2.9?

Hmm that shouldn't be the case, I think? In both 2.4 and 2.9.x (and all later versions), neither .prepareCommit nor .commit wait for merges. That said, if a merge happens to complete before you call those methods, then it is in fact committed. Mike On Tue, Oct 5, 2010 at 1:13 PM, Mark Harwood

Merge and commit behaviour - changed between 2.4 and 2.9?

Having upgraded a live system from 2.4 to 2.9.3 the client is reporting a change in merge behaviour that is causing some issues with their update monitoring logic. The suggestion is that any merge operations now complete as part of the IW.prepareCommit() call rather than previously when they ra

Re: Different analyzer on a different field

org.apache.lucene.analysis.PerFieldAnalyzerWrapper -- Ian. On Tue, Oct 5, 2010 at 9:40 PM, liat oren wrote: > Hi, > > Is it possible to use WhitespaceAnalyzer in one field and another analyzer > in a differnt field? > If it is, how should it be written? > > Many Thanks, > Liat > ---

Different analyzer on a different field

Hi, Is it possible to use WhitespaceAnalyzer in one field and another analyzer in a differnt field? If it is, how should it be written? Many Thanks, Liat

Re: Numeric range query not returning results

More problem with NumericRangeQuery when combined it with BooleanQuery. Here are the problem, please help. 1. I have a field of Date that is indexed as long 2. In the search, I need to exclude some time period, I used the BooleanQuery to combined those excluded time periods like below, BooleanQuer

Re: Safely closing stale IndexReaders

2010/10/5 Mindaugas Žakšauskas : > The key bit: release(searcher) here calls IndexReader.decRef() which > in turn closes the index when necessary. Ahh yes. > This approach has the same disadvantage of object pooling I have > mentioned in my original email. The "do searching & rendering" phase >

Re: Safely closing stale IndexReaders

Hi, Thanks for your input Mike. As far as I understand, your suggestion is to do something like this: IndexSearcher searcher = searcherManager.get(); try { // do searching & rendering here… } finally { searcherManager.release(searcher) ; } The key bit: release(searcher) here calls IndexRead

Re: Matching Documents BitSet

Filter.bits( IndexReader ). These have since been deprecated and removed from the lucene API in 3.x. I have figured out how to produce the equivalent in the latest version of the API. Thanks though. Jordon On Oct 5, 2010, at 2:03 AM, Ian Lea wrote: > How do you do this in 2.x? > > > -- >

Re: Recreate segment infos

I'm not sure how it vanished, I think it was on a Solr rsync based replication operation, and a lack of disk space. Need to move to the Java replication and get larger SSD drives, working on both, at least they're SSDs, making some progress. I was going to recover using the IDs in the terms dict

Re: Safely closing stale IndexReaders

Check out the SearcherManager class in Lucene in Action 2nd edition's source code. It's free for download at Manning's site (http://manning.com/lucene). NOTE: I am one of the co-authors. I think that class does exactly what you're seeking. It uses reference counts to ensure a reader is closed a

Re: Merge policy, optimization for small frequently changing indexes.

Have you considered having fewer indexes, each storing data for multiple users? Obviously with some indexed field that you can use for restricting searches to data for that user. I believe that is more common practice for this sort of scenario and is known to work well. You seem to be adding pos

Re: Recreate segment infos

How did you lose your segments file...? This was discussed before but I don't think the idea ever turned into a tool. I think it should be possible. You'd have to sort all files, deriving segment names from the prefixes. Then, you have to reconstruct the metadata required for SegmentInfo. EG o

Re: Merge policy, optimization for small frequently changing indexes.

Thank you, Ian I have a large number of dynamically changing Index, so calling expungeDeletes() and optimize() is very costly. At this point I am opting to just set a optimum merge factor and skip optimize() On Tue, Oct 5, 2010 at 2:54 PM, Ian Lea wrote: > Deleted docs will be removed by lucene

Safely closing stale IndexReaders

Hi, I am keeping a ConcurrentMap of o.a.l.index.IndexReader which I use in my system. These readers are retrieved by multiple threads and I have no knowledge when these readers are actively used and when not. When underlying index is updated, I reopen the reader and replace it in the map: IndexR

Re: Merge policy, optimization for small frequently changing indexes.

Deleted docs will be removed by lucene at some point - there is no need to run optimize. Read the javadocs for IndexWriter for details. See also expungeDeletes(). That may be just what you need. -- Ian. On Tue, Oct 5, 2010 at 7:48 AM, Naveen Kumar wrote: > Hi > I have one more question, does

Re: Need help regarding Lucene Document Iteration...

What exactly is the problem? The standard idiom nowadays for iterating through a List is what you're using in "for (Field field : ...)". I haven't used an iterator for a long time. But perhaps your iteration code is working and the problem is in your search code. The javadoc for search(query, n

Re: Matching Documents BitSet

How do you do this in 2.x? -- Ian. On Mon, Oct 4, 2010 at 8:10 PM, Jordon Saardchit wrote: > In lucene 3, is there an equivalent to obtaining a BitSet of documents from > an Index as there was in version 2.x?  I'm trying to put together an upgrade > path. > > Thanks! ---