Bug #2549
closed
XQuery using saxon:stream leaves open thread in 9.7
Applies to branch:
9.6, 9.7
Fix Committed on Branch:
9.6, 9.7
Fixed in Maintenance Release:
Description
In 9.7, iterating an XQuery result leaves an open thread, when the query accesses input via saxon:stream and does not process it completely.
Attaching a test program that demonstrates this behaviour.
Files
- Category set to Streaming
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Fix Committed on Branch 9.7 added
Thanks for the clear test case.
When the iterator is closed, the idea is that the whole chain of underlying iterators should be closed, and eventually the iterator that reads from the provider thread signals the provider thread to close. But within the chain of underlying iterators is a ContextMappingIterator, which supports a construct such as A!B where there are two nested iterators, one for A and one for B. The iterator for A is being closed, but that for B is not, and it is the iterator for B that is connected to the provider thread.
Fixed by a patch to ContextMappingIterator.close().
Note: MappingIterator gets this right, it's only ContextMappingIterator that gets it wrong.
- Applies to branch 9.6 added
- Fix Committed on Branch 9.6 added
The same problem is present in 9.6 and I have applied the patch there also.
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.7.0.2 added
Bug fix applied in the Saxon 9.7.0.2 maintenance release
Thank you for taking care of this.
Meanwhile I have retested with Saxon 9.7.0.2. Though it does not happen in each iteration any more, there is still a chance of some thread being left over. The number varies in repeated executions of the test.
I have modified my test (now ThreadCountTest2) to show the stack traces of the left-over threads, and they all look the same:
number of threads increased from 6 to 8
Thread-1791
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:353)
com.saxonica.ee.stream.PushToPull$QueueWriter.write(PushToPull.java:63)
com.saxonica.ee.stream.PushToPull$Provider.run(PushToPull.java:95)
java.lang.Thread.run(Thread.java:745)
Thread-1793
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
java.util.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue.java:353)
com.saxonica.ee.stream.PushToPull$QueueWriter.write(PushToPull.java:63)
com.saxonica.ee.stream.PushToPull$Provider.run(PushToPull.java:95)
java.lang.Thread.run(Thread.java:745)
Some further testing showed that the rate still is 1 thread left over per iteration of the test, when waiting some time before issuing close calls:
xdmSequenceIterator.next();
Thread.sleep(100);
xdmSequenceIterator.close();
xqueryEvaluator.close();
Please register to edit this issue
Also available in: Atom
PDF