On 30/08/16 21:52, Andy Seaborne wrote:
At a quick glance ...
Doesn't the data bag need to clear up somehow?
If QueryIteratorDistinct.requestSubCancel() is called,
eventually QueryIteratorDistinct.closeSubIterator is
called and if the data bag is being used it is closed.
Reading the stack trace I just generated, this is because
QueryExecutionBase.close has been called and the close
trickles down the iterator tree.
(The data bag is only used if ARQ.spillToDiskThreshold
is set and the set `seen` of seen bindings gets bigger
than that size. Our production systems don't use
spill-to-disc anyway.)
Andy
On 30/08/16 15:51, Chris Dollin wrote:
Dear All
possible problem in QueryIterDistinct.requestSubCancel()
We have been having problems with timeouts on some of our
production servers. On certain queries, timeouts of some
tens of seconds do not appear to fire, no results are
generated by the query, and the query continues to
consume a CPU. If left long enough (more than an hour)
the query finally terminates in a NullPointerExplosion.
We have been able to replicate the issue using generated
data and a slimmed-down query with four triples and
DISTINCT.
Investigation with the debugger led us to QueryIterDistinct's
requestSubCancel method. Unlike other requestSubCancel
declarations, its body is not empty and it specifically
super.closes the current iterator. Further, following the
chain of cancel-requestCancel methods from the
invocation of the timeout shows that the cancels stop
here.
We think that the cancellation protocol is satisfied
by having QueryIterDistinct.requestSubCancel have
an empty body, but we're not sure we've understood
it completely. Certainly removing requestSubCancel's
body removed the presenting problem, with the query
timing out cleanly.
I'll submit a JIRA with the data generator and
query when I've clreaned it up a bit, but I
thought a heads-up would be a good idea (and maybe
our reading of the cancel protocol is worng ...)
Chris
--
"Possibly you're not recalling some of his previous plans." Zoe, /Firefly/
Epimorphics Ltd, http://www.epimorphics.com
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Epimorphics Ltd. is a limited company registered in England (number 7016688)
