The machine runs NTPD (and it is not virtual – only the windows one is virtual running on this linux server as VM). But NTPD never does changes on wall time, it only slows down or boosts up the clock speed by instructing the Linux kernel to do so. Wall-Clock changes are only happening on machine boot up when ntpdate init.d corrects the clock manually before starting ntpd. But at that time no tests are running. The windows machine in the VM uses the ntpd provided by the host linux machine on the internal, virtual interface. As Windows is not failing but uses the same clock source (syncing at latest every 3600 secs to outer NTPD), the issue is not NTPD J
Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen <http://www.thetaphi.de/> http://www.thetaphi.de eMail: [email protected] From: Robert Muir [mailto:[email protected]] Sent: Wednesday, December 05, 2012 7:54 PM To: [email protected] Subject: Re: TestSqlEntityProcessorDelta failures on Policeman Jenkins On Wed, Dec 5, 2012 at 1:14 PM, Dyer, James <[email protected]> wrote: When the full import ends, it writes the last index timestamp in a file called "dataimport.properties". Unimaginably, this file only records precision to seconds. The delta updates use this recorded timestamp to know which documents changed since the last import. To handle this in the test, it pads the "last modified" column values in the rdbms so we shouldn't get strange failures due to timing issues. My chief worry is that I did this incorrectly and maybe Policeman is a little faster or something and can trip a timing issue. So yesterday I committed a whole bunch of logging on this test to try and see what is happening. But strangely it hasn't failed since then whereas it was failing multiple times per day. But it only fails on Linux. I wonder if the problem is the timestamp? Maybe Uwe runs NTPD on his Linux virtual machine? (just a crazy out-there idea). That would definitely make it hard to reproduce.
