Dear All
We think we've spotted a bug in ARQs SortedDataBag.
During operation of our Fuseki servers (we're running
Fuseki 2.4.1 wi. with timeouts) we saw log entries
of the form
WARN QueryIteratorCheck :: Open iterator: QueryIterOptionalIndex/-
1454412710
for (some, intermitent) queries with sorting.
Exploring the code found something suggestive in
QueryIterSort.SortedBindingIterator
which takes as a constructor parameter qIter, and
keeps as a like-named instance variable, the iterator
whose content is to be sorted. It's close() method
closes the data bag but /not/ the underlying qIter.
If SortedBindingIterator.initializeIterator() pulls
all of the items from qIter into the databag,
it will auto-close that iterator. If initialization
runs to completion, closing the sorted binding
iterator will /not/ close that iterator. So whether
it is closed will depend on how loaded Fuseki
is.
We verified that under normal (non-cancelled) circumstances
closing a SortedBindingIterator did not close the
underlying iterator (qIter, above) by tweaking
TestQueryIterSort.testCleanAfterCode to check that
after QueryIterSort iterator has been closed its
underlying iterator has also been closed. (This
required making TestQueryIterSort.iterator public.)
This modified test fails, as we'd expect.
Making SortedBindingIterator.close() perform qIter.close()
makes the modified test pass, again as we'd expect?
So.
Is the non-closing behaviour of SortedBindingIterator intended
or is it, as we think, a fixable bug? I'm happy to raise a JIRA
if that's appropriate and provide a pull request.
Chris
