On 06/06/17 16:10, Stefan Seelmann wrote:
The two disks are identical and configured as a linux soft RAID array.
They are Hitachi HDS721010CLA332s - 1 Tb 7200 rpm.
I'm sure that's the cause. I also tried to build ApacheDS on a server
with spinning disks, and it takes forever. I assume that we just do too
many sync's when writing data to disk during the tests.
@Emmanuel: Is it possible to disable sync-on-write?
I seem to remember my "solution" was to implement some rather nasty
synchronized static semaphores with finalizers to allow each of the
several threads within a single test unit to follow each-other's
progress. I also had to configure jUnit to only run one test unit at a
time (to protect the statics). It was tricky and ugly, but I was
desperate to have every test always run properly on any platform. I
presume this is a surefire problem, not apacheds?
To make matters more depressing, I decided to do a clean checkout of M24
on my laptop, which is super-slow by comparison. That failed much
earlier (goal apacheds-core-api - missing dependencies) and I will post
those details separately when I get back home again in a couple of hours
from now.
That's probably another reason: The API 1.0.0 which ApacheDS M24 depends
on is not yet available in public Maven repo. On your other machine you
built it yourself and thus it's in you local maven repo.
You are correct! I copied my local API sandbox to the laptop and then
re-ran mvn clean. It now fails in exactly the same way as my desktop, i.e.
[INFO] Apache Directory API All ........................... SUCCESS [
8.239 s]
[INFO] Apache Directory LDAP API Client All ............... SUCCESS [
6.523 s]
[INFO] Apache Directory API Integration Tests ............. SUCCESS [
33.313 s]
[INFO] Apache Directory API OSGi Integration Tests ........ FAILURE [
59.170 s]
[INFO] Apache Directory API OSGi Integration Tests 2 ...... SKIPPED
[INFO] Apache Directory LDAP API Distribution ............. SKIPPED
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 05:57 min
[INFO] Finished at: 2017-06-06T17:12:59+10:00
[INFO] Final Memory: 49M/405M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test
(default-test) on project api-integ-osgi: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: The
forked VM terminated without properly saying goodbye. VM crash or
System.exit called?
[ERROR] Command was /bin/sh -c cd
/home/brian/sandboxApache/ldap-api-1.0.0/integ-osgi &&
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -Xmx1024m -jar
/home/brian/sandboxApache/ldap-api-1.0.0/integ-osgi/target/surefire/surefirebooter7386057830129872783.jar
/home/brian/sandboxApache/ldap-api-1.0.0/integ-osgi/target/surefire/surefire806017378512191980tmp
/home/brian/sandboxApache/ldap-api-1.0.0/integ-osgi/target/surefire/surefire_157233883319047368199tmp
(It isn't too late to fire me from the developers team!! I wanted to
help, but it doesn't look like I am yet!)
Don't be depressed, your feedback is very helpful! It shows that our
software is too big and the build is too complex etc. (but I don't know
how to improve and too less time...)
Perhaps you can't change it at the moment, but don't you think it is
"wrong" that the directory build doesn't include the API?
I think it is excellent that the API can be built stand-alone. (I might
even consider converting some old applications which still use a private
copy of the final Netscape LDAP API, along with a LOT of my own
modifications, which work well against apacheds M23).
On the other hand, it seems strange that the directory build, which
depends heavily on the API, doesn't build its own copy if one isn't
already available...
Kind Regards,
Stefan
Thanks very much for your encouragement. I'll do my best to be
constructive with my observations.
Brian
