On 31/03/17 16:40, Chris Dollin wrote:
Hi Andy
Yes, the cancel thread doesn't call open(), I understand
that.
is that "close()" not "open()"?
The warnings are intermittent because the iterator
in question (the "source" interator of QueryIterSort)
is only left open if the cancel request is noticed while
the sort databag is filling up.
QueryIterSort never explicitly closes the source
iterator. But if the sort databag pulls all of the
source bindings, the source iterator self-closes.
So there's a window while the bag is filling when
a detected cancellation will leave the source
iterator open.
A fix is to ensure that the source iterator
is closed when QueryIterSort closes:
@Override public void closeIterator() {
and also:
this.db.close();
c.f. requestCancel
embeddedIterator.close();
super.closeIterator();
}
"embeddedIterator" is the source iterator.
SortedDataBag: add close() to cancel:
public void cancel() {
comparator.cancel();
close();
}
This fix eliminates the presenting problem and
the tests continue to pass /except/ that
CallBackIterator's close() method needs to
be made a no-op rather than failing, since
that open() is now actually called.
close()?
[It looks like QueryIterTopN has the same problem]
It would do no harm to have the same close processing in QueryIterTopN
though it does not use data bags because it is an unconditional single
pass over the data.
Have you seen warnings in the TopN case?
Andy
Chris
On 20 March 2017 at 15:48, Chris Dollin <[email protected]>
wrote:
On 17 March 2017 at 17:08, Andy Seaborne <[email protected]> wrote:
SortedDataBag.cancel does not call close.
You're quite right, am having another look at the problem.
Chris
