Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of tomasflobbe@gmail.com
 designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAHsXEHXMs4RZ-Coesdy6zi5CCMfh2eDzcbQqtE8fmUYDi6Cj=g@mail.gmail.com>
References: 
 <CAHsXEHWJxHq=s1it_nqfkHjcPEY7PdAYA=wgx6uC_AadM1kgAQ@mail.gmail.com>
	<538381C1.4060201@elyograg.org>
	<CAHsXEHXMs4RZ-Coesdy6zi5CCMfh2eDzcbQqtE8fmUYDi6Cj=g@mail.gmail.com>
Date: Tue, 27 May 2014 04:52:30 -0700
Message-ID: 
 <CAMJgJxR-FjBeDbtNa+zWjXVHNM_=wqnX6b+wjNNwJui04xQ6Tg@mail.gmail.com>
Subject: Re: How to Configure Solr For Test Purposes?
From: =?UTF-8?B?VG9tw6FzIEZlcm7DoW5kZXogTMO2YmJl?= <tomasflobbe@gmail.com>
To: solr-user@lucene.apache.org
Content-Type: multipart/alternative; boundary=001a1133ed7a9bab6704fa605428

--001a1133ed7a9bab6704fa605428
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> What do you suggest for my purpose? If a test case fails re-running it fo=
r
> some times maybe a solution? What kind of configuration do you suggest fo=
r
> my Solr configuration?
>
>
>From the snippet of test that you showed, it looks like it's testing only
Solr functionality. So, first make sure this is a test that you really
need. Solr has it's own tests, and it you feel it could use more (for some
specific case or context), I'd open a Jira and try to get the test inside
Solr.
If my impression is wrong and your test is actually testing your code, then
I'd suggest you to use a specific soft commit call with waitSearcher =3D tr=
ue
on your test instead of relying on the autocommit (and remove the
autocommit completely from your solrconfig).

Tom=C3=A1s


Thanks;
> Furkan KAMACI
> 26 May 2014 21:03 tarihinde "Shawn Heisey" <solr@elyograg.org> yazd=C4=B1=
:
>
> > On 5/26/2014 10:57 AM, Furkan KAMACI wrote:
> > > Hi;
> > >
> > > I run Solr within my Test Suite. I delete documents or atomically
> update
> > > them and check whether if it works or not. I know that I have to setu=
p
> a
> > > hard/soft commit timing for my test Solr. However even I have that
> > settings:
> > >
> > >      <autoCommit>
> > >        <maxTime>1</maxTime>
> > >        <openSearcher>true</openSearcher>
> > >      </autoCommit>
> > >
> > >        <autoSoftCommit>
> > >          <maxTime>1</maxTime>
> > >        </autoSoftCommit>
> >
> > I hope you know that this is BAD configuration.  Doing automatic commit=
s
> > on an interval of 1 millisecond is asking for a whole host of problems.
> >  In some cases, this could do a commit after every single document that
> > is indexed, which is NOT recommended at all.  The openSearcher setting
> > of "true" on autoCommit makes it even worse.  There's no reason to do
> > both autoSoftCommit and autoCommit with openSearcher=3Dtrue.  I don't k=
now
> > which one "wins" between autoCommit and autoSoftCommit if they both hav=
e
> > the same config, but I would guess the hard commit does.
> >
> > > and even I wait (Thread.sleep()) for a time to wait Solr *sometimes* =
my
> > > tests are failed. I get fail error even I increase wait time.  Exampl=
e
> > of a
> > > sometimes failed code piece:
> > >
> > > for (int i =3D 0; i < dummyDocumentSize; i++) {
> > >          deleteById("id" + i);
> > >          dummyDocumentSize--;
> > >          queryResponse =3D query(solrParams);
> > >          assertTrue(queryResponse.getResults().size() =3D=3D
> > dummyDocumentSize);
> > >       }
> > >
> > > at debug mode if I wait for Solr to reflect changes I see that I do n=
ot
> > get
> > > error. What do you think, what kind of configuration I should have fo=
r
> > such
> > > kind of purposes?
> >
> > Chances are that commits are going to take longer than 1 millisecond.
> > If you're actively indexing, the system is going to be trying to stack
> > up lots of commits at the same time.  The maxWarmingSearchers value wil=
l
> > limit the number of new searchers that can be opened, but it will not
> > stop the commits themselves.  When lots of commits are going on, each
> > one will take *even longer* to complete, which probably explains the
> > problem.
> >
> > Thanks,
> > Shawn
> >
> >
>

--001a1133ed7a9bab6704fa605428--