Hi Bhaskar,
the answer is very simple: Your analysis is not useful for the type of queries
and data you are using. You are using SimpleAnalyzer in your search/indexing
code:
https://lucene.apache.org/core/5_3_1/analyzers-common/org/apache/lucene/analysis/core/SimpleAnalyzer.html
"An Analyzer th
Hi Uwe,
Below is my indexing code:
public static void main(String[] args) throws Exception {
//Path indexDir = new Path(INDEX_DIR);
public static final String INDEX_DIR = "c:/DBIndexAll/";
final Path indexDir = Paths.get(INDEX_DIR);
SimpleDBIndexer indexer = new SimpleDBIndexer();
try{
Class.f
Hi Noble,
Is there something we could improve about the release check list to
reduce the chance of these sorts of mistakes in the future?
Mike McCandless
http://blog.mikemccandless.com
On Tue, Sep 29, 2015 at 4:36 PM, Terry Smith wrote:
> Noble,
>
> Everything looks good now, thank you.
>
> -
No, it is not possible to disable, and, yes, we removed that API in
5.x because 1) the risk of silent index corruption is too high to
warrant this small optimization and 2) we re-worked how merging works
so that this checkIntegrity has IO locality with what's being merged
next.
There were other pe
Ok So I'm a little confused:
The 4.10 JavaDoc for LiveIndexWriterConfig supports volatile access on a
flag to setCheckIntegrityAtMerge ...
Method states it controls pre-merge cost.
Ref:
https://lucene.apache.org/core/4_10_0/core/org/apache/lucene/index/LiveIndex
WriterConfig.html#setCheckInte
Yes, the indexing workflow is completely separate from the runtime system. The
file system is EMC Isilon via NFS.
Jim
From: will martin
Sent: 29 September 2015 14:29
To: java-user@lucene.apache.org
Subject: RE: Lucene 5 : any merge performance metrics c
This sounds robust. Is the index batch creation workflow a separate process?
Distributed shared filesystems?
--will
-Original Message-
From: McKinley, James T [mailto:james.mckin...@cengage.com]
Sent: Tuesday, September 29, 2015 2:22 PM
To: java-user@lucene.apache.org
Subject: Re: Lucene
Hi Adrien and Will,
Thanks for your responses. I work with Selva and he's busy right now with
other things, so I'll add some more context to his question in an attempt to
improve clarity.
The merge in question is part of our batch indexing workflow wherein we index
new content for a given par
So, if its new, it adds to pre-existing time? So it is a cost that needs to be
understood I think.
And, I'm really curious, what happens to the result of the post merge
checkIntegrity IFF (if and only if) there was corruption pre-merge: I mean if
you let it merge anyway could you get a false
Noble,
Everything looks good now, thank you.
--Terry
On Tue, Sep 29, 2015 at 1:26 AM, Noble Paul wrote:
> Please check now
>
> On Mon, Sep 28, 2015 at 8:42 PM, Noble Paul wrote:
> > Looks like I missed it , I shall upload it soon
> >
> >
> > On Mon, Sep 28, 2015 at 7:59 PM, Terry Smith wrot
Indeed this is new but I'm a bit surprised this is the source of your
issues as it should be much faster than the merge itself. I don't
understand your proposal to check the index after merge: the goal is to
make sure that we do not propagate corruptions so it's better to check the
index before the
Patching Lucene 4 would be quite hard I'm afraid.
Le mer. 16 sept. 2015 à 16:58, Sascha Janz a écrit :
> Hi,
>
> we use lucene 4.6 in our project. we got some perfomamce problems with
> IndexSearcher.doc(int docID, SetfieldsToLoad). i found this issue
> https://issues.apache.org/jira/browse/LUC
12 matches
Mail list logo
