OK, thanks for bringing closure!
Mike McCandless
http://blog.mikemccandless.com
On Mon, Aug 15, 2016 at 7:19 AM, Daniq wrote:
> I've simplified the test and it works OK. Possibly it was very deep
> simplification) but likely the initial problem is in code from our side.
>
>
> Daniq wrote
> > O
I've simplified the test and it works OK. Possibly it was very deep
simplification) but likely the initial problem is in code from our side.
Daniq wrote
> Ok, I'll try it a bit later.
> Thank you.
> Michael McCandless-2 wrote
>> No, casing issues would not be random; it was just what I noticed in
Ok, I'll try it a bit later.
Thank you.
Michael McCandless-2 wrote
> No, casing issues would not be random; it was just what I noticed in your
> test case.
>
> Can you fix the casing issue in your test case and confirm it's still
> failing and if so, simplify the test case further, e.g. remove t
No, casing issues would not be random; it was just what I noticed in your
test case.
Can you fix the casing issue in your test case and confirm it's still
failing and if so, simplify the test case further, e.g. remove the context
manager and create a Lucene Document directly, and then see if it's
Can casing issue appear randomly? Because tests not fail constantly, they are
blinking.
Daniel.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Synchronous-Lucene-index-update-tests-occasionally-fail-tp4283970p4284657.html
Sent from the Lucene - Java Users mailing list arch
It looks like you have a casing issue maybe?
You indexed variableWithHelpString.
But searched for variablewithhelpstring*
Mike McCandless
http://blog.mikemccandless.com
On Mon, Jun 27, 2016 at 5:07 AM, Baskakov Daniel wrote:
> I've just noticed that not only dynamic adding/removing entities
I've just noticed that not only dynamic adding/removing entities tests
fail, but also a simple indexing.
Here is a boiled down structure of the test:
@BeforeClass
public static void beforeClass() throws Exception
{
// ContextManager is a domain model
contextManager = createContextMa
Can you boil this down to a small standalone test case showing the issue?
Mike McCandless
http://blog.mikemccandless.com
On Mon, Jun 27, 2016 at 4:03 AM, Baskakov Daniel wrote:
> Thank you Mike.
>
> Commit is performed after each indexing op in unit tests only:
>
> public void commitNow() th
Thank you Mike.
Commit is performed after each indexing op in unit tests only:
public void commitNow() throws IOException
{
if (getIndexWriter().hasUncommittedChanges())
{
getIndexWriter().commit();
}
}
In production environment I have a timer that performs commit periodi
You must reopen your IndexReader to see recent changes to the index.
But, IW.commit after each indexing op is very costly.
It's much better to get near-real-time readers, e.g. from a SearcherManager
that you pass your IW instance too, after each set of changes that you now
need to search.
As lon
10 matches
Mail list logo
