java-snappy fails as a dependency of several Java evaluations, for
example:

http://ci.guix.gnu.org/eval/120281?status=failed
http://ci.guix.gnu.org/build/359649/log/raw

These failures exist only on ci.guix.gnu.org, but locally it build
perfectly, even with --rounds=100!

Why? Because our buildmachine has too much memory :-) [And I can
remember, we once had that for another package, I just can't remember
again which one].

What should we do about it? Just disable the test, or something more
complicated?

Analysis:

To analyze, I let it once fail with the -K switch to have the directory

/tmp/guix-build-java-snappy-1.1.7.drv-0/

available. Enter the environment with

$ guix environment java-snappy
$ cd /tmp/guix-build-java-snappy-1.1.7.drv-0/
$ source ./environment-variables
$ cd source
$ ant check
--> everything is fine.  

Then increase the memory used by junit: Edit the build.xml file, add a
huge "maxmemory" property like this :

<junit maxmemory="30G" printsummary="true" ...

Either have enough RAM or add some extra swap space, then run again:

$ ant check

It fails. The junit logs can be found in

src/test/test-reports/TEST-org.xerial.snappy.pool.CachingBufferPoolTest.txt

Testsuite: org.xerial.snappy.pool.CachingBufferPoolTest
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.363 sec

Testcase: testDirectByteBuffers took 0.002 sec
Testcase: testSoftReferences took 7.353 sec
        FAILED
count: 2048
junit.framework.AssertionFailedError: count: 2048
        at org.xerial.snappy.pool.CachingBufferPoolTest.testSoftReferences(Unknown
Source)

Testcase: testArrays took 0 sec
Testcase: testAdjustSize took 0 sec

If you look at the test case source code, it tries to allocate about
20GB and hopes that this fails. It just does not fail on huge machines...

Björn