Hi,
The problem here is not only tests. If you run 2 ANT builds in parallel there are more things that fail horribly (you get javac errors because of half-written class files, copy tasks corrumpting each other while copying resource, JAR tasks…). You cannot fix that unless you re-write the whole ANT build system. And because of that there is also no reason to change test environment like you propose. In my opinion, the better way would be to “lock” the whole checkout and prevent parallel ANT runs. > BTW, doesn't the runner mkdirs() J0,J1 etc.? After I set the builds to > tempDir/job1 and tempDir/job2, I hit FNFE, until I manually created these > dirs. It makes them, but the parent dirs must be existing, see ANT build file. The problem is running tests from Eclipse, which is “working somehow” but does not correctly separate and set up the build environments. The java.io.tmpdir sysprop is only set by the ANT build from the ANT script, the junit4 task does not modify the property at all – as Eclipse does not run the ant script, you have to configure java.io.tempdir yourself. Uwe P.S.: If you see Jenkins failing on those builds, it’s happening because Jenkins was not able to kill all processes of the previous build when you hit “cancel build”. In that case the following build and tests will fail because of the reasons I mentioned above. Otherwise Jenkins has a separate build dir for every build, so the above “cannot kill all processes” is a “bug” in Jenkins (the problem is missing process management in Java, so there is no portable way to kill processes from Java…). ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen <http://www.thetaphi.de/> http://www.thetaphi.de eMail: u...@thetaphi.de From: Shai Erera [mailto:ser...@gmail.com] Sent: Sunday, December 23, 2012 9:58 AM To: dev@lucene.apache.org Subject: Re: improving unique work.dir per JVM? It's not about Jenkins letting two build plans to run from the same directory, but rather where you set tempDir to. If both are set to say java.io.tmpdir, then you get a collision. I configured both builds to set a unique tempDir, and that's working fine so far. Was just thinking that it'll be easier if we appended the PID to the dir. It just makes it even more unique, though I understand your point about losing the ability to debug when you have too many J0-<PIDs>. BTW, doesn't the runner mkdirs() J0,J1 etc.? After I set the builds to tempDir/job1 and tempDir/job2, I hit FNFE, until I manually created these dirs. Shai On Sun, Dec 23, 2012 at 10:49 AM, Dawid Weiss <dawid.we...@cs.put.poznan.pl> wrote: I would say separating builds should be the duty of a build container. If Jenkins somehow allows two build plans to run from the same directory then I think it's either a bug or a risky feature. This said, there are also downsides of appending anything that changes (per-run) to build directories -- you won't be able to tell where your JVMs (and their output files) are created, if stuff is left behind you'll have an incremental mess from which it'll be hard to determine what's recent, what's stale, what failed, etc. I know this for a fact because I initially created current working directories in a temporary folder (at random). It was hell. Dawid On Sun, Dec 23, 2012 at 8:43 AM, Shai Erera <ser...@gmail.com> wrote: > Hi > > Today each JVM receives its own work.dir, e.g. J0, J1 and so forth. I think > I've hit on my Jenkins an error that was caused due to overlapping builds, > one deleted the work.dir of the other. > > So maybe we can do a best effort to detect the PID and if success, append it > to work.dir, e.g. J0_9324? If the JVM ManagementBean is able to return a > parseable PID, then we use it, otherwise we stick w/ J0. > > Is it possible? > > In the meanwhile, I've configured my Jenkins to not run overlapping builds. > > Shai --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
