Rob mainly:
My changes are only to files in commands but the failure is an ARQ
system test failure. Bother.
Modified:
/jena/trunk/jena-arq/src/main/java/arq/query.java
/jena/trunk/jena-tdb/src/main/java/tdb/cmdline/ModTDBDataset.java
The test failure is
org.apache.jena.riot.lang.
TestStreamedRDFIterators.streamed_tuples_iterator_01
see
https://builds.apache.org/job/Jena__Development_Test/org.apache.jena$jena-arq/421/testReport/org.apache.jena.riot.lang/TestStreamedRDFIterators/streamed_tuples_iterator_01/
== http://s.apache.org/CAP
In run #422 a different test failure occured:
TestStreamedRDFIterators.streamed_quads_iterator_07
TestStreamedRDFIterators.streamed_tuples_iterator_07
But test the test works for me locally.
- - - - - - - - - - - -
The problem seems to be timing between the two threads. Given that the
Jenkins server is usually heavily loaded, this isn't surprising.
The producer has not be scheduled, stream.start() has not been called.
Maybe the call to get the Future provokes its thread to get scheduled
first, or it might be simply luck.
Suggestions:
I haven't been able to try this out yet:
1/ (test change) Call stream.start() immediately the
StreamedTuplesIterator is created.
2/ (test change) Put a lock between the two threads.
System changes:
3/ Make StreamedRDFIterator<T>.hasNext blocking even before .start
called (or automatically call)
4/ Is .start enforcement needed?
Andy
PS Unrelated:
.next() does not call .hasNext. Would the code have less duplication
with all the sync code in one place in hasNext.
(it's pattern that has come up for me quite a lot - complicated hasNext,
simple next, when a one slot lookahead is needed.)
next() {
if ( ! hasNext() ) throw nosuchelement
T t = next ;
next = null ;
return t ; }
?
