[jira] Commented: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput

[ https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614290#action_12614290 ] Michael McCandless commented on LUCENE-753: --- {quote} In our implementation the s

Hudson build is back to normal: Lucene-trunk #529

See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/529/changes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (LUCENE-1313) Ocean Realtime Search

[ https://issues.apache.org/jira/browse/LUCENE-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Rutherglen updated LUCENE-1313: - Attachment: lucene-1313.patch lucene-1313.patch - Depends on LUCENE-1314 - OceanSegment

IndexReader.acquire()/release() ?

I'd like to propose a patch for IndexReader but before I file a proper bug and attach the (simple) patch, I want to check here if my approach is the right one. I have a server where a bunch of threads are handling search requests. I have a another process that updates the index used by the searc

Re: IndexReader.acquire()/release() ?

Hey Andi, I think that the best way of dealing with this, as there is little downside and it avoids further complicating IndexReader, is to build your reference counting around the IndexReader class rather then within it. - Mark Andi Vajda wrote: I'd like to propose a patch for IndexReader

Re: IndexReader.acquire()/release() ?

Hey Andi, I think that the best way of dealing with this, as there is little downside and it avoids further complicating IndexReader, is to build your reference counting around the IndexReader class rather than within it. - Mark Andi Vajda wrote: I'd like to propose a patch for IndexReader

[jira] Created: (LUCENE-1338) With non-deprecated constructors, IndexWriter's autoCommit is always true

With non-deprecated constructors, IndexWriter's autoCommit is always true - Key: LUCENE-1338 URL: https://issues.apache.org/jira/browse/LUCENE-1338 Project: Lucene - Java

[jira] Commented: (LUCENE-1338) With non-deprecated constructors, IndexWriter's autoCommit is always true

[ https://issues.apache.org/jira/browse/LUCENE-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614404#action_12614404 ] Ning Li commented on LUCENE-1338: - Or is the intention to make autoCommit always false aft

lucene expert wanted

My client based in west London. is looking for a Search expert to help with Text retrieval and that is used to dealing with very large volumes of data etc . candidates will ideally be experts in Lucene but may well have exp of verity or nutch . the client is uses all the latest cutting edge ope

[jira] Commented: (LUCENE-1338) With non-deprecated constructors, IndexWriter's autoCommit is always true

[ https://issues.apache.org/jira/browse/LUCENE-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614457#action_12614457 ] Michael McCandless commented on LUCENE-1338: bq. Or is the intention to make a

[jira] Resolved: (LUCENE-1337) [PATCH] improve searching under high concurrancy

[ https://issues.apache.org/jira/browse/LUCENE-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-1337. Resolution: Duplicate Lucene Fields: [New, Patch Available] (was: [Patch Av

[jira] Resolved: (LUCENE-1338) With non-deprecated constructors, IndexWriter's autoCommit is always true

[ https://issues.apache.org/jira/browse/LUCENE-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ning Li resolved LUCENE-1338. - Resolution: Invalid When deprecated constructors are removed in 3.0, autoCommit will always be false.

[jira] Commented: (LUCENE-1337) [PATCH] improve searching under high concurrancy

[ https://issues.apache.org/jira/browse/LUCENE-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614475#action_12614475 ] Jason Rutherglen commented on LUCENE-1337: -- The problem is the same but the solut

[jira] Updated: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput

[ https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-753: -- Attachment: FSDirectoryPool.patch I attached FSDirectoryPool.patch, which adds oal.sto

[jira] Commented: (LUCENE-1337) [PATCH] improve searching under high concurrancy

[ https://issues.apache.org/jira/browse/LUCENE-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614483#action_12614483 ] Michael McCandless commented on LUCENE-1337: Jason are you thinking of LUCENE-

[jira] Commented: (LUCENE-1337) [PATCH] improve searching under high concurrancy

[ https://issues.apache.org/jira/browse/LUCENE-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614519#action_12614519 ] Jason Rutherglen commented on LUCENE-1337: -- Yonik checked in a modification of FS

Index without tf, anyone?

hi all, is there any solution to have pure postings lists without interleaved tf ... this eats a lot of CPU for VInt decoding on dense terms (also doubles IO...) in our case. Can be a untested patch, tips how to do it or whatever... I know about flexible indexing, but cannot wait (I guess it w

Re: Index without tf, anyone?

On Jul 17, 2008, at 1:57 PM, eks dev wrote: is there any solution to have pure postings lists without interleaved tf ... this eats a lot of CPU for VInt decoding on dense terms (also doubles IO...) in our case. To decompress integers really quickly, we shouldn't even be using VInts. We