Hi,

as you might now, I’m currently working hard on untangling a bit of IoTDB’s 
build.
Unfortunately, I now know, why all READMEs refer to using “-DskipTests”.
It turns out that our build in its current form has a number of cycles in them.
The probably most problematic one is that client-cpp needs the distribution to 
run its integration-tests
and distribution bundles client-cpp … this is a classic cycle in maven.

So, if I try to build IoTDB after a clean, at least this module will fail, as 
distribution is empty and the failure is a bit hard to diagnose at first.

It would be good, if that integration-test wasn’t requiring distribution to be 
built first.
As I’ve done so in my Apache Historian experiment, I know we could just run 
IoTDB from the JVM of the maven build and run it locally in the current modules 
target directory.
This has the benefit of the processes being killed after the build 
automatically.

I usually have the process viewer open while running the builds, as I have to 
kill zombie iotdb processes, if the build fails.

This brings me to the next problem … we always run the tests on the default 
ports … this means if we have zombies running around, it is impossible to build 
as many tests will fail.

We could also use this IoTDB Test Started to start IoTDB on random available 
ports.
This would eliminate the problem of being blocked by zombie processes, and also 
enable me to run the build as parallel build.
My Mac has way too many cores to just let one do the work, so I usually run 
builds in parallel.
However, with us using static ports, this is not possible, as if two modules 
run tests in parallel, that need access to these ports, only one will succeed.


What do you think?

Chris

Reply via email to