Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of dawid.weiss@gmail.com
 designates 209.85.210.176 as permitted sender)
Received-SPF: pass (google.com: domain of dawid.weiss@gmail.com designates
 10.50.149.162 as permitted sender) client-ip=10.50.149.162;
MIME-Version: 1.0
Sender: dawid.weiss@gmail.com
In-Reply-To: <004301ccee83$64668ab0$2d33a010$@thetaphi.de>
References: 
 <CAM21Rt8zanD03cY3sOBA-xAk=xOEKV=twim=LX0442ya-JVAjA@mail.gmail.com>
 <CAOdYfZWMckNpnNpB-X=GafOw5ozmEc7NrnmkvupdOcxb2-gvrA@mail.gmail.com>
 <CAM21Rt-8Ogoj_K8EP2Um7PmNQ+5oo=nXieTwuY=WCOxtyrJCkQ@mail.gmail.com>
 <CAOdYfZV-VoGqjCy=P7GnEmJEy7VpFu9qHDDqU+1zNttBGepL1g@mail.gmail.com>
 <CAM21Rt_triLGq_mi3T4L5Y809Lj2dRte9hXHb3fMnYT1Ep=Pww@mail.gmail.com>
 <004301ccee83$64668ab0$2d33a010$@thetaphi.de>
From: Dawid Weiss <dawid.weiss@cs.put.poznan.pl>
Date: Sat, 18 Feb 2012 22:30:33 +0100
Message-ID: 
 <CAM21Rt-seAEGKaJMP76TyMiiL_s=-cM0vNDo5k7Dr0sKtEVYmA@mail.gmail.com>
Subject: Re: [important] Refactoring of tests infrastructure.
To: dev@lucene.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> :-) It would be great if we could ever have that, but I don=E2=80=99t thi=
nk that=E2=80=99s possible!
> Most non-reproducibility in Lucene came from multi-threaded tests where t=
he different threads interact with > each other... And that cannot be solve=
d in any case without serial execution.

If there are race conditions in threads involved in the suite (or if
there are unpredictable timing schedules resulting from network or
disk operations) then sure -- it's an impossible case. But race
conditions shouldn't be a result of sharing a single random generator;
it's possible to avoid that by giving each thread its own copy of a
Random instance if it asks for one (predictably initialized to the
same starting seed from each thread). This is effectively a
thread-local randomness and ensures any call sequence to it from
within a thread will be reproducible. I've implemented this as part of
RandomizedRunner and it works really well. Upgrading to
RandomizedRunner is a long-term goal though, I need to refactor LTC in
smaller steps to avoid going insane ;)

You could even go a step further and make sure Randoms are not shared
by locking-in and verifying the owner thread in each call... This
would break a LOT of existing tests though -- I don't have any
estimates how much effort would be needed to straighten these up.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org