> :-) It would be great if we could ever have that, but I don’t think that’s > possible! > Most non-reproducibility in Lucene came from multi-threaded tests where the > different threads interact with > each other... And that cannot be solved 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: [email protected] For additional commands, e-mail: [email protected]
