IRITest fails on openJDK 6 about owlapi HOT 3 CLOSED

If Travis is slow enough (and it is fairly slow), the 12 or so seconds that the two long IRITest's take locally on my fast developer machine may legitimately stretch out to longer than 60 seconds.

To determine whether that is it, you can reduce the number of iterations through the test loop (and the number of threads if necessary) and see if it starts passing.

from owlapi.

I have got that result on a local build in a virtual machine - slightly
slower than running in my host OS, but I shouldn't expect it to take that
long.
However, worth experimenting.
I.

On 28 May 2013 23:55, Peter Ansell [email protected] wrote:

If Travis is slow enough (and it is fairly slow), the 12 or so seconds
that the two long IRITest's take locally on my fast developer machine may
legitimately stretch out to longer than 60 seconds.

To determine whether that is it, you can reduce the number of iterations
through the test loop (and the number of threads if necessary) and see if
it starts passing.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-18585743
.

from owlapi.

You were right on the speed issue - increasing the timeout made the deadlock problem go away on my machine.
The javadoc problem is not reproducible with my OpenJDK 6 (v 1.6.0_27, IcedTea6 1.12.5, Maven 3.0.4, on Lubuntu running in VirtualBox).

Given that Java 6 is already out of the public update period, and OpenJDK 6 appears to be in bug fix mode only, I might disable the Travis build and run my local build regularly to avoid continuous false alarms and not leave Java 6 users high and dry with a non-working or non-buildable system.

from owlapi.