The security manager only prevents writing of files outside the build directory, but it cannot restrict the JVMs to only write into their own working directory…. We could try this at some time, but then also the JUnit4 CarrotSearch stuff must respect this. So if all tests running in parallel share the same config directory, then can drive crazy. So the timestamp file should be *private* to the test, so the tests should store them in their working directory (as reported by the temporary directory functions in LuceneTestCase).
The issue only happens on Policeman server in Linux, but not in Windows, because Windows VM only uses one JVM to run tests, while Linux uses 2 parallel JVMS… The FreeBSD one is also running with 2 JVMs, but this server runs the test much more seldom because it has a lot of other stuff to do… James: How many JVMs does your machine use (you see this at the beginning when tests start to run)? 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 8:11 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: Robert, Thank you for taking time on this!! The test first does a full import with 20 documents. Then it randomly chooses to add,modify and/or delete documents from the rdbms then does a delta import. It then checks that the index now has the correct # of documents and that they match the actual changes to the rdbms. The failures are always on the delta imports. The failure on this seed is that it is does a query and expects 22 results but it only gets 20 back. When the full import ends, it writes the last index timestamp in a file called "dataimport.properties". ok next theory: where does this dataimport.properties actually go? is it possible multiple jvms could have a race on this same file? I vaguely feel like in the past maybe this file dangerously sat in the solr configuration directory, but on the other hand I thought we had some more SecurityManager protection these days and/or the situation was improved.
